VMware Hands-on Labs - HOL-1704-SDC-1-JA


実習ラボの概要: HOL-1704-SDC-1: vSphere 6 のパフォーマンスの最適化

実習ラボのガイダンス


使用できる時間は実習ラボのセッションあたり 90 分です。各モジュールの横に、それぞれの予定所要時間が表示されています。 どのモジュールも単独で完了できるため、ランダムに受講することができますが、各モジュールの完了後のクリーンアップに関する手順には慎重に従ってください。各モジュールの完了後には、モジュールで指示されているスクリプトを使用してすべての仮想マシンをシャットダウンする必要があります。この実習ラボには、合計 6 時間以上の内容が含まれています。

実習ラボのモジュールのリスト

実習ラボの概要

モジュール 1: CPU パフォーマンス、基本概念、トラブルシューティング (15 分)

モジュール 2: CPU パフォーマンス機能: 待ち時間感度設定 (45 分)

モジュール 3: CPU パフォーマンス機能: 電力ポリシー (15 分)

モジュール 4: CPU パフォーマンス機能: SMP-FT (30 分)

モジュール 5: メモリ パフォーマンス、基本概念、トラブルシューティング (30 分)

モジュール 6: メモリ パフォーマンス機能: メモリのホット アドを使用した仮想 NUMA (30 分)

モジュール 7: ストレージ パフォーマンスとトラブルシューティング (30 分)

モジュール 8: ネットワーク パフォーマンス、基本概念、トラブルシューティング (15 分)

モジュール 9: ネットワーク パフォーマンス機能: 予約機能を備えた Network I/O Control (45 分)

モジュール 10: パフォーマンス ツール: esxtop CLI の概要 (30 分)

実習ラボ責任者: David Morse、Jim Sou

この実習ラボ マニュアルは、次のハンズオン ラボ ドキュメント サイトからダウンロードできます。

http://docs.hol.pub/catalog/


 

メイン コンソールの場所

 

  1. メイン コンソールは、図の赤枠で囲った領域に表示されます。 実習ラボ マニュアルは、メイン コンソールの右側のタブに表示されます。
  2. 実習ラボによっては、左上の別のタブに追加のコンソールが用意されていることがあります。その場合は、実習ラボ マニュアルの説明に従って、指定されたコンソールを開いてください。
  3. この実習ラボでは、開始時に 90 分のタイマーが表示されます。 このラボで行った作業内容は保存できません。 すべての作業は、実習ラボ セッション内に完了してください。 時間が足りない場合は、[延長] をクリックして時間を延長することができます。 VMware イベントでご使用の場合は、実習ラボの時間を 2 回まで、最大 30 分延長できます。 [延長] を 1 回クリックすると、時間が 15 分間延長されます。 VMware イベント以外でご使用の場合は、実習ラボの時間を最大 9 時間 30 分延長できます。[延長] を 1 回クリックすると、時間が 1 時間延長されます。

 

 

アクティベーション プロンプトまたはウォーターマーク

 

実習ラボを初めて開始したときに、Windows がアクティベーションされていないことを示すウォーターマークがデスクトップに表示される場合があります。 

仮想化の大きなメリットの 1 つは、仮想マシンを任意のプラットフォームに移動して実行できることです。 ハンズオン ラボは、このメリットを活用して複数のデータセンターから実習ラボを実行できるようになっています。 ただし、データセンターによってプロセッサのタイプが異なることがあり、そのような場合、インターネット経由で Microsoft 社のアクティベーション チェックが行われます。

しかし問題はありません。VMware とハンズオン ラボは、Microsoft 社のライセンス要件に完全に準拠しているので、安心してご利用いただけます。 お使いの実習ラボは自己完結型のポッドであり、Windows のアクティベーションの確認で必要となるインターネットへの完全なアクセスはありません。 アクティベーション チェックの自動プロセスは、インターネットへの完全なアクセスを行わないと失敗します。このようなウォーターマークが表示されるのはそのためです。

これは表面上の問題であり、実習ラボに対する影響はありません。 

 

 

キーボード以外の方法によるデータ入力

このモジュールでは、メイン コンソールでテキストを入力します。複雑なデータを入力する場合、キーボードから直接入力する以外に、次の 2 つの方法を使用すると入力しやすくなります。

 

 

クリック アンド ドラッグによるコピー

実習ラボ マニュアルに記載されているテキストやコマンド ライン インターフェイス (CLI) のコマンドを、クリック アンド ドラッグでメイン コンソールのアクティブ ウィンドウに直接コピーすることができます。 

 

 

オンラインの国際キーボードの使用

 

キーボード配列によっては、特定の文字や記号が入力しにくいことがあります。そのような場合、メイン コンソールに、オンラインの国際キーボードを表示して使用できます。

  1. オンライン キーボードは、Windows のクイック起動タスク バーで、キーボードのアイコンをクリックして表示します。

 

 

アクティブなコンソール ウィンドウのクリック

 

この例では、E メール アドレスで使用される 「@」 記号をオンライン キーボードから入力します。US 配列のキーボードで 「@」 記号は <Shift> + <2> キーを押して入力します。

  1. アクティブなコンソール ウィンドウを 1 回クリックします。
  2. <Shift> キーをクリックします。

 

 

@>キーのクリック

 

  1. <@> キーをクリックします。

アクティブなコンソール ウィンドウに @ 記号が入力されました。

 

 

画面右下でラボの準備完了を確認

 

画面の右下の [Lab Status] で、ラボの準備が完了したことを確認します。表示が [Ready] になったことを確認して、学習を開始してください。[Ready] になるまで数分間かかります。 5 分経過しても [Ready] にならない場合は、サポートにお問い合わせください。

 

vSphere 6 のパフォーマンスの概要


この実習ラボ HOL-SDC-1704 では、vSphere のパフォーマンスを高めるためのベスト プラクティスと、vSphere 6 で使用できるさまざまなパフォーマンス関連の機能について説明します。VMware Lab の 「Fling」 や esxtop などのさまざまなソリューションやツールを操作し、vSphere 環境のパフォーマンスを測定して診断します。パフォーマンス関連の vSphere 機能には、Network I/O Control の予約機能、メモリのホット アドを使用した仮想 NUMA、待ち時間感度設定、電力ポリシー設定などがあります。

この実習ラボの時間の制約から例にあげるパフォーマンスの問題の数は限られていますが、vSphere 環境によく見られる関連性の高い問題が選択されています。 これらの例を学習すると、一般的なパフォーマンスの問題を理解して解決するのが容易になります。 

詳細なパフォーマンス トラブルシューティングの手法と VMware ベストプラクティスの一覧については、次の vmware.com の Web サイトをご覧ください。

http://www.vmware.com/files/pdf/techpaper/VMware-PerfBest-Practices-vSphere6-0.pdf

http://pubs.vmware.com/vsphere-60/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-60-monitoring-performance-guide.pdf

また、パフォーマンス関連の記事に関心がある場合は、VMware VROOM! ブログをチェックしてください。

http://blogs.vmware.com/performance/


Control Center ブラウザ言語設定(日本語)

Firefox ブラウザ言語設定 (日本語表示) (copied)


vSphere Web Clientはブラウザベースです。日本語表示するためには、ブラウザの言語設定を日本語に設定します。

なお、vSphere Web Client 以外の一部ツールでは英語表記となります。これはハンズオンラボ環境特有のものです。


 

Firefoxの起動

 

Firefoxアイコンをクリックし、 起動します。

 

 

Firefoxブラウザの日本語化

 

1. ウィンドウ右上のメニューを開きます。

2. [Options]  をクリックします。

 

 

Firefoxブラウザの日本語化

 

左側メニューから [Content] を選択します。

 

 

Firefoxブラウザの日本語化

 

[Languages] の [Choose...] をクリックします。

 

 

Firefoxブラウザの日本語化

 

[Select a language to add...] をクリックします。

 

 

Firefoxブラウザの日本語化

 

1. プルダウンから [Japanese [ja] ] を選択します。

2. [Add] をクリックします。

3. [OK] をクリックします。

4. Firefox を再起動します。

 

Google Chrome ブラウザ言語設定(日本語表示) (copied)


vSphere Web Client はブラウザベースです。日本語表示にする為には、ブラウザの言語設定を日本語に設定します。

なお、vSphere Web Client 以外の一部ツールでは英語表記となります。これはハンズオンラボ環境特有のものです。


 

Google Chrome の起動

 

Google Chrome を起動します。

 

 

Google Chrome のメニューを開く

 

ブラウザウィンドウ右上のメニューを開きます。

 

 

Google Chrome の設定画面を開く

 

[Settings] をクリックします。

 

 

Google Chrome の詳細設定を表示

 

1. 画面を下へスクロールします。

2. [Show advanced settings...] をクリックします。

 

 

Google Chrome の言語と入力の設定

 

画面を下へスクロールし、[Language and input setting...] をクリックします。

 

 

Google Chrome の言語と入力の設定

 

[Add] をクリックします。

 

 

Google Chrome の言語と入力の設定

 

1. プルダウンから [Japanese - 日本語] を選択します。

2. [OK] をクリックします。

 

 

Google Chrome の言語と入力の設定

 

1. 左側 [Languages] 内の [Japanese] を一番上までドラッグで移動させます。

2. [Done] をクリックします。

3. Google Chrome ブラウザを再起動します。

 

モジュール 1: CPU パフォーマンス、基本概念、トラブルシューティング (15 分)

CPU パフォーマンスのトラブルシューティングの概要


このモジュールでは、仮想化環境の CPU 競合の問題を紹介しています。 さまざまなパフォーマンス メトリックと設定をチェックして、パフォーマンスの問題を素早く特定する方法も説明しています。

需要を満たすのに十分な CPU リソースがないとパフォーマンスに問題が生じる場合があります。vSphere ホストでの CPU リソースの過剰な需要が生じるにはいくつかの理由があります。場合によっては、原因は単純です。vSphere ホストに非常に多くの仮想マシンを導入して処理が集中するアプリケーションを実行すると、すべての仮想マシンに十分な CPU リソースを供給できなくなります。しかし使用可能なリソースが効率よく使用されていない、あるいは仮想マシンの構成が最適化されていないなど、もっと些細な原因が理由の場合もあります。

それでは、始めます。


 

US キーボード以外をご使用のユーザーの方へ

 

US 配列以外のキーボードが接続されたデバイスをご使用の場合は、この実習ラボのモジュールを進める中で CLI コマンドやユーザー名、パスワードが入力しづらいと感じる場合があるかもしれません。

入力する必要のある CLI コマンド、ユーザー名、パスワードは、デスクトップにあるファイル README.txt からコピーしてペーストできます。

 

 

スクリーン キーボード

 

キーボードの入力に問題がある場合のもう 1 つの解決策として、スクリーン キーボードを使用する方法があります。 

それには、[Start] メニューから [On-Screen Keyboard] を選択するか、タスクバーのショートカットをクリックします。

 

 

元の状態への復帰

 

何らかの理由で操作を間違えた場合や実習ラボを中断した場合は、次の操作を実行して元の状態に戻し、現在のモジュールを最初からやり直してください。

タスクバーの [VMware vSphere PowerCLI] アイコンをクリックして PowerCLI シェル プロンプトを開きます。

 

 

モジュール再開のための仮想マシンのリセット

 

PowerCLI プロンプトで次のように入力します。

.\StopLabVMs.ps1

<Enter> キーを押します。

実行中のすべての仮想マシンが停止してその設定がリセットされ、モジュールを再開できるようになります。

 

 

このモジュールの開始

 

このモジュールを開始しましょう。

タスクバーのショートカットから Chrome を起動します。

 

 

vSphere へのログイン

 

vSphere にログインします。デフォルトのホーム ページは vSphere Web Client です。

何らかの理由でこの認証が機能しない場合は、このチェックボックスをオフにして次の認証情報を使用してください。

ユーザー名: CORP\Administrator
パスワード: VMware1!

 

 

UI の更新

 

この実習ラボでの手動入力を減らすために、多数のタスクがスクリプトで自動化されています。そのため、スクリプトの実行直後は、vSphere Web Client にインベントリの実際の状態が反映されていない可能性があります。

インベントリを手動で更新する必要がある場合は、vSphere Web Client の上部にある [Refresh] アイコンをクリックします。

 

 

[ホストおよびクラスタ] の選択

 

 

vSphere HTML5 Web Client


このモジュールでは、HTML5 バージョンの Web Client を利用することもできます。 このバージョンは即応性と安定性に優れており、同時にセキュリティも確保できるように設計されています。 

現在、Fling リリースでは使用できない機能があります。 最もよく使用するアクションや機能は次のとおりです。

各自の環境でこのクライアントを実行するには、https://labs.vmware.com/flings/vsphere-html5-web-clientを参照してください。

このモジュールで行う操作の大半は HTML5 バージョンでは機能しないため、ご注意ください。ここでは、Flash と HTML5 の両方のインスタンスを同時に開き、切り替えて使用することをおすすめします。

HTML5 Web Client は、[RegionA HTML5 Client] というラベルのブックマーク セクションにあります。


 

HTML5 Web Client のリンク

 

 

 

 

Fling とは

Fling の Web サイト (https://labs.vmware.com/about) から抜粋

VMware のエンジニアは、空き時間に長年温めてきた大量のプロジェクトに取り組んでおり、そのプロジェクト (「Fling」) に関するフィードバックを常に求めています。Fling と名付けられた理由は、Fling には短期間のシリアスではなく楽しい関係という意味があるためです。同様に、ここに用意されているツールは、ご自由に使用して検討していただくことができます。どのツールも、今後の製品サービスに組み込まれる保証はなく、サポートもされません。ただし、完全に無償でダウンロードし、お試しいただくことができます。

 

 

CPU 競合


次に、CPU のパフォーマンスに関する非常に一般的な問題の一覧を示します。

高い Ready 時間: 仮想マシンを実行できる状態にありながら、vSphere が仮想マシンを実行する物理リソースを見つけられず実行できない場合に、CPU は Ready 状態となります。Ready 時間が 10 % を超える場合は CPU の競合の可能性があり、CPU に負荷の集中するアプリケーションのパフォーマンスに影響を与えることがあります。ただし、一部の CPU 依存が少ないアプリケーションや仮想マシンは、Ready 時間の値が高くても問題なく、十分なパフォーマンスを得られる場合があります。

高い Costop 時間: Costop 時間は、必要以上の仮想 CPU があることと、仮想 CPU が過剰に構成されているために仮想マシンのパフォーマンスを低下させるオーバーヘッドが発生していることを示します。仮想マシンの動作は、仮想 CPU の数が少ないほうが向上する傾向にあります。Costop の値が高い仮想 CPU は、その他の比較的アイドル状態にある仮想 CPU がビジー状態の仮想 CPU に追いつくまで、実行されなくなります。

CPU 制限: CPU 制限は、仮想マシンが設定された量を超える CPU リソースを使用するのを直接制限します。CPU 制限により、仮想マシンが制限以上のリソースを必要とする場合に CPU パフォーマンスに問題が発生する可能性があります。

ホスト CPU の飽和: vSphere ホストの物理 CPU が一貫して 85 % 以上使用されているとき、vSphere ホストは飽和します。vSphere ホストが飽和すると、スケジューラが仮想マシンを実行するための空き物理 CPU リソースを見つけるのが困難になります。

ゲスト CPU の飽和: ゲスト CPU (仮想 CPU) の飽和は、仮想マシン内のアプリケーションが仮想マシンに割り当てられた CPU リソースの 90 % 以上を使用する場合に発生します。これは、アプリケーションで仮想 CPU リソースのボトルネックが生じていることを示します。この場合は、仮想マシンに仮想 CPU リソースを追加することでパフォーマンスが改善することがあります。

オーバーサイジング状態の仮想マシンの仮想 CPU: 大規模な Symmetric Multi-Processing (SMP) 仮想マシンを使用すると、不要なオーバーヘッドが生じることがあります。仮想マシンには、実行する予定のアプリケーションに適したサイズを設定する必要があります。アプリケーションによっては、サポートされるマルチスレッドが特定のスレッド数に制限される場合があります。 仮想マシンに仮想 CPU を追加して割り当てることで、さらにオーバーヘッドが増すこともあります。 仮想 CPU 使用率から、複数の仮想 CPU で構成されているマシンが 1 つの仮想 CPU しか使用していないと考えられる場合、仮想マシン内部のアプリケーションが追加の仮想 CPU キャパシティを利用できないか、ゲスト OS が正しく構成されていない可能性があります。

低ゲスト使用率: ゲスト CPU の使用率が低い場合は、アプリケーションが正しく設定されていないか、またはアプリケーションで I/O やメモリなどのほかのリソースが不足して、割り当てられた仮想 CPU リソースを十分使用できていない可能性があります。


 

PowerCLI ウィンドウを開く

 

タスクバーの [VMware vSphere PowerCLI] アイコンをクリックしてコマンド プロンプトを開きます。

 

 

CPU ワークロードの開始

 

PowerCLI コンソールから

次のように入力します。

.\StartCPUTest.ps1

<Enter> キーを押します。

スクリプトが構成され、仮想マシンが起動するまでの間、先を読み進んでください。

 

 

CPU テストの開始

 

スクリプトが完了したら、2 つのリモート デスクトップ ウィンドウが開きます (注: スクリーンショットのように並べて表示するには、いずれかのウィンドウの移動が必要になる場合があります)。

スクリプトにより CPU 負荷の高いベンチマーク (SPECjbb2005) が perf-worker-01a と perf-worker-01b の両方の仮想マシンで実行され、このワークロードの実行時に GUI にリアルタイムのパフォーマンス値が表示されます。

SPECjbb2005 ウィンドウが開いていない場合は、左上隅にあるショートカットを使って起動します。

このスクリーンショットは、ベンチマークのパフォーマンスが約 15,000 である場合の例を示しています。

重要: 実習ラボ環境の負荷の変化によって、実際の値はスクリーンショットの値と異なる場合があります。

 

 

perf-worker-01a (仮想マシン レベル) のパフォーマンス チャートへの移動

 

  1. 左側の仮想マシン リストから perf-worker-01a 仮想マシンを選択します。
  2. [監視] タブをクリックします。
  3. [パフォーマンス] をクリックします。
  4. [詳細] をクリックします。
  5. [チャートオプション] をクリックします。

 

 

CPU パフォーマンスを監視するためのカウンタの選択

 

CPU の問題の可能性を調べる際に分析することが重要となるカウンタがあります。

  1. チャート メトリックの [CPU] を選択します。
  2. perf-worker-01aオブジェクトのみをオンにします。
  3. カウンタ リストの右下にある [None] をクリックします。
  4. [需要]、[準備完了]、[使用量(MHz単位)] のみをオンにします。
  5. [OK] をクリックします。

 

 

CPU 状態時間の説明

 

仮想マシンには次の 4 つのいずれかの高レベル CPU 状態があります。

 

 

需要量と使用量のグラフの監視

 

この仮想マシンで要求される CPU の量を確認して、仮想マシンに実際に割り当てられた CPU 使用量 (Usage in MHz) と比較します。仮想マシンの需要量が、現在使用可能な量を超えています。

仮想マシンの 準備完了 時間も増えていることがわかります。

ガイダンス: 準備完了 時間が 10 % を超えるとパフォーマンスに問題が発生します。

 

 

値の変換について

 

注: vCenter では 「Ready 時間」 などの一部のメトリックがミリ秒 (ms) で報告されます。ミリ秒 (ms) からパーセンテージに値を変換するには、この式を使用してください。

複数の仮想 CPU を持つ仮想マシンの場合、サンプル時間に仮想マシンの仮想 CPU の数をかけてサンプル時間の合計を求めます。複数の仮想 CPU を持つ仮想マシンでは、Co-Stop 時間を監視するのも役に立ちます。 Ready 時間と同様に、Co-Stop 時間が 10 % を超えるとパフォーマンスの問題が発生します。 Ready 時間と Co-Stop メトリックは、仮想マシンごとだけでなく仮想 CPU ごとに確認できます。 仮想 CPU ごとに確認したほうが精度の高い統計情報が得られます。

 

 

ホスト レベルの CPU チャート ビューへの移動

 

  1. esx-01a.corp.local を選択します。
  2. [監視] タブを選択します。
  3. [パフォーマンス] を選択します。
  4. [詳細] ビューを選択します。
  5. [CPU] ビューを選択します。

 

 

ESX ホスト レベルの CPU メトリックの調査

 

チャートでは、ホストの CPU の 1 つだけに大きなワークロードが実行されていることがわかります。

1 つの CPU が 100 % で、ホストのその他の CPU は使用されていません。

 

 

perf-worker-01a の設定の編集

 

perf-worker-01a の構成方法を見てみましょう。

  1. perf-worker-01a 仮想マシンをクリックします。
  2. [アクション] をクリックします。
  3. [設定の編集] をクリックします。

 

 

perf-worker-01a のアフィニティ設定の確認

 

  1. リストの [CPU] 項目を展開して、アフィニティが cpu1 に設定されていることを確認します。
  2. 「1」 を消去して、システムの物理 CPU における仮想マシンのバランスを正しく設定します。
  3. [OK] をクリックして変更を確定します。

注: ほとんどの場合、VMware ではアフィニティの設定を推奨しません。 CPU における仮想マシンのバランスは vSphere によって最適に設定されるため、アフィニティを手動で指定する必要はありません。 アフィニティを有効にすることで vMotion などの一部の機能の妨げになり、管理上の問題が生じることや、今回診断したようなパフォーマンスの問題につながる場合があります。

 

 

perf-worker-01b のアフィニティ設定の確認

 

  1. リストの [CPU] 項目を展開して、アフィニティが設定されていることを確認します。両方の仮想マシンが同じプロセッサ (CPU1) にバインドされた不適切な設定になっています。これは、管理者が仮想マシンのアフィニティを設定し、オリジナルをクローンして 2 つ目の仮想マシンを作成した場合に起こります。
  2. 「1」 を消去して、システムの物理 CPU における仮想マシンのバランスを正しく設定します。
  3. [OK] をクリックして変更を確定します。

注: ほとんどの場合、VMware ではアフィニティの設定を推奨しません。 CPU における仮想マシンのバランスは vSphere によって最適に設定されるため、アフィニティを手動で指定する必要はありません。 アフィニティを有効にすることで vMotion などの一部の機能の妨げになり、管理上の問題が生じることや、今回診断したようなパフォーマンスの問題につながる場合があります。

 

 

Ready 時間の監視

 

perf-worker-01a に戻り、[準備完了] 時間がすぐに下がって [使用量(MHz単位)] が増えていることを確認します。

 

 

パフォーマンスの向上

 

少し時間がかかりますが、CPU ベンチマーク スコアを向上させたいところです。 リモート デスクトップ ウィンドウをクリックして再度表示し、これを確認します。

この例では、需要メトリックと使用済み CPU のメトリックを比較して、CPU の競合を確認しました。 準備完了 時間のメトリックについて、物理 CPU の競合を見つける方法を紹介しました。アフィニティ設定の問題点も説明しました。

 

 

perf-worker-01b の設定の編集

 

パフォーマンス向上のために perf-worker-01b に仮想 CPU を追加しましょう。

  1. perf-worker-01b 仮想マシンをクリックします。
  2. [アクション] をクリックします。
  3. [設定の編集] をクリックします。

 

 

perf-worker-01b への CPU の追加

 

  1. CPU の数を [2] に変更します。
  2. [OK] をクリックします。

 

 

perf-worker-01b の CPU パフォーマンスの監視

 

  1. perf-worker-01b を選択します。
  2. [監視] を選択します。
  3. [パフォーマンス] を選択します。
  4. [CPU] ビューを選択します。

仮想マシンで両方の仮想 CPU が使用されていることを確認します。これは、仮想マシンの OS で CPU のホット アドがサポートされており、その機能が仮想マシンで有効になっているためです。

 

 

パフォーマンスの調査

 

仮想 CPU を追加したため、perf-worker-01b のパフォーマンスが向上しました。

ただし、この方法が必ずしも功を奏するとは限りません。仮想マシンが実行されているホスト (esx-01a) に物理 CPU が 2 つしかない場合は、仮想 CPU を追加するとオーバーコミットが発生し、Ready の割合が高くなってパフォーマンスが低下します。

ほとんどのワークロードは、必ずしも CPU バウンドであるとは限らないことに注意してください。 OS とアプリケーションは、CPU の追加によるパフォーマンス向上のためマルチスレッド化が可能である必要があります。 OS が実行するほとんどの処理は通常は CPU バウンドではなく、ほとんどの時間を命令の実行よりも、ユーザー操作、デバイス入力、データ取得などの外部イベントの待機に費やします。それ以外の未使用の CPU サイクルを使用することで仮想化のオーバーヘッドを吸収できるため、これらのワークロードは通常、ネイティブと同等のスループットとなります。ただし、遅延は若干増える可能性があります。

仮想マシンに構成する仮想 CPU をワークロードで使用可能な数より増やすと、リソース使用量がわずかに増加し、非常に高負荷のシステムでパフォーマンスに影響が出る可能性があります。一般的な例は、複数の仮想 CPU を搭載した仮想マシンでシングルスレッドのワークロードを実行する場合、またはワークロードが効果的に使用できる量を超えた仮想 CPU を搭載した仮想マシンでマルチスレッド ワークロードを実行する場合です。

ゲスト OS が割り当てられている仮想 CPU の一部を使用しない場合でも、仮想マシンに構成している仮想 CPU が多すぎると、ESXi にゼロ以外のリソース要求が課せられ、ホストで実際に CPU が消費される結果となります。次に例を示します。

これらのリソース要求により、ホストで実際に CPU が消費される結果となります。

 

 

リモート デスクトップ接続の終了

 

2 つのリモート デスクトップ接続を閉じます。

 

まとめとクリーンアップ


この実習ラボの残りの部分を実行できるようにリソースを解放するために、使用した仮想マシンをシャットダウンして構成をリセットする必要があります。


 

PowerCLI の起動

 

PowerCLI ウィンドウをまだ開いていない場合は、タスクバーの [VMware vSphere PowerCLI] アイコンをクリックしてコマンド プロンプトを開きます。

 

 

仮想マシンのパワーオフとリセット

 

PowerCLI コンソールで次のように入力します。

.\StopLabVMs.ps1

<Enter> キーを押します。

実行中のすべての仮想マシンが停止してその設定がリセットされます。

 

 

PowerCLI ウィンドウを閉じる

 

PowerCLI ウィンドウを閉じます。

これで別のモジュールに進むことができます。

 

 

要点

CPU 競合の問題は一般的に検出が容易です。実際に vCenter では、ホスト CPU の使用率や仮想マシンの CPU 使用率が高い期間が続くと通知されるアラームがいくつかあります。

vSphere 6.0 では、最大 128 の仮想 CPU を持つ非常に大規模な仮想マシンを作成できます。実行するアプリケーション ワークロードに適したサイズを仮想マシンに設定するようにしてください。ワークロードが実際に使用できるよりも必要以上に多くのリソースを仮想マシンに設定すると、ハイパーバイザーのオーバーヘッドが生じて、パフォーマンスの問題が発生する可能性があります。

一般的な CPU パフォーマンスのヒントをいくつかあげます。

小規模のプラットフォームで大きなサイズの仮想マシンを避ける

ビジーなワークロードには処理が容易なワークロードのように高い統合率を期待できない

 

 

まとめ

 

これで、「モジュール 1: CPU パフォーマンス、基本概念、トラブルシューティング」 は終了です。実習ラボをご利用いただきありがとうございました。 最後にアンケートへのご記入をお願いします。

時間が残っている場合は、この実習ラボに含まれているほかのモジュールが、それぞれの予定所要時間とともに表示されます。 マニュアル内のモジュールにすばやく移動するには、[More Options] - [Table of Contents] の順にクリックします。

 

モジュール 2: CPU パフォーマンス機能: 待ち時間感度設定 (45 分)

待ち時間感度の概要


待ち時間感度機能の目的は、仮想化によって発生する遅延の増加の主な原因を取り除き、応答時間の短縮とジッターの低減を実現することにあります。この仮想マシン単位の機能では、共有によるリソースの競合を防ぐために物理リソースへの排他的アクセス権を付与し、追加の処理のオーバーヘッドを排除するために仮想化レイヤーをバイパスして、オーバーヘッドを軽減するために仮想化レイヤーを調整することで、この目的を達成します。待ち時間感度機能と Single Root I/O Virtualization (SR-IOV) などのパススルー メカニズムを併用すると、パフォーマンスはさらに向上します。

待ち時間感度機能は仮想マシン単位で適用されるため、vSphere ホストでは、通常の仮想マシンと待ち時間感度が高い仮想マシンを組み合わせて実行できます。


 

この機能を有効に利用できるケース

待ち時間感度は、遅延を非常に少なくする必要がある特殊なユースケースを想定した機能です。この機能がワークロードにメリットをもたらすかどうか、機能を有効にする前に判断することが極めて重要です。待ち時間感度を使用するとネットワーク遅延を極限まで少なくできますが、これはリソース共有量を減らすことによる CPU とメモリのコスト増との引き換えであり、電力消費量も増加します。

「待ち時間感度が高いアプリケーション」 とは、ネットワーク遅延が数十ミリ秒程度で通信状態がほぼ安定していることが必要なアプリケーションを指します。たとえば、証券取引アプリケーションは待ち時間感度が高いアプリケーションです。

待ち時間感度の設定が正しいかどうか判断する前に、アプリケーションのネットワーク遅延要件を確認する必要があります。待ち時間感度を 「高」 に設定すると、ホストの CPU 使用率と消費電力量が増加する可能性があり、場合によってはパフォーマンスに悪影響が出ることがあります。

 

 

この機能を有効に利用できないケース

待ち時間感度機能を有効にするとネットワーク遅延が低減します。ストレージの遅延またはネットワーク以外のほかのリソースの遅延が影響している遅延の場合は、待ち時間感度を使用してもアプリケーションの遅延は減少しません。

待ち時間感度機能は、CPU がアンダーコミット状態にある環境で有効にする必要があります。待ち時間感度を 「高」 に設定した仮想マシンには、実行に必要な物理 CPU への排他的アクセス権が付与されます。つまり、待ち時間感度が高い仮想マシンは、近隣の仮想マシンと CPU を共有できなくなります。

通常、待ち時間感度機能を使用する仮想マシンには、ホストのソケットあたりのコア数より少ない仮想 CPU を搭載し、待ち時間感度が高い仮想マシンに NUMA ノードが 1 つしか占有されないようにする必要があります。

実際の環境で待ち時間感度機能を使用しない場合、別のモジュールを選択してください。

 

 

CPU アクセスの変更点

仮想マシンの待ち時間感度が vCenter Server に 「高」 と設定されている場合、仮想マシンは実行する必要のある物理コアに排他的にアクセスできます。これは排他的アフィニティと呼ばれます。これらのコアは待ち時間感度が設定された仮想マシン専用に予約されます。その結果、仮想マシンから CPU へのアクセス性能が向上し、ほかの仮想マシンから同じコアへの多重アクセスによる L1 キャッシュおよび L2 キャッシュの負荷が軽減されます。仮想マシンがパワーオンされているとき、各仮想 CPU は特定の物理 CPU に割り当てられ、その CPU 上にとどまります。

待ち時間感度が設定された仮想マシンの仮想 CPU がアイドルのとき、ESXi は通常の停止動作も変更し、物理 CPU をアクティブのままにします。そのため、仮想マシンが再度アクティブになったときのウェイクアップ遅延が短縮します。

 

 

仮想 NIC 割り込み統合の変更点

仮想 NIC とは、VMkernel とゲスト OS との間でネットワーク パケットを交換する仮想デバイスのことです。交換は通常、ゲスト OS への割り込みまたはゲスト OS から VMkernel へのコールによりトリガされますが、両方とも高いコストがかかる操作です。仮想 NIC 割り込み統合は vSphere でデフォルトで有効になっている動作であり、ハイパーバイザーが仮想マシンを起動する頻度が上がる割り込みをトリガするまでのしばらくの間パケットを保持する (パケットを組み合わせる、つまり 「統合する」) ことで、CPU オーバーヘッドの削減を試みる動作です。

待ち時間感度を 「高」 に設定すると仮想 NIC 統合が無効になるため、パケット送受信時と CPU のパケット処理中断時の間に生じる遅延が減少します。  通常、スループットの向上 (CPU の中断頻度を下げる) にはこの統合が適していますが、これにより、ネットワークが遅延したり不安定になったりする可能性があります。

この統合を無効にすると遅延を軽減できますが、CPU 使用率、ひいては消費電力量が増加する可能性もあります。 そのため、このオプションは、パケット レートが低く CPU に十分な余裕がある環境でのみ使用してください。

実習の準備はできましたか。実習を始めましょう。

 

 

US キーボード以外をご使用のユーザーの方へ

 

US 配列以外のキーボードが接続されたデバイスをご使用の場合は、この実習ラボのモジュールを進める中で CLI コマンドやユーザー名、パスワードが入力しづらいと感じる場合があるかもしれません。

入力する必要のある CLI コマンド、ユーザー名、パスワードは、デスクトップにあるファイル README.txt からコピーしてペーストできます。

 

 

スクリーン キーボード

 

キーボードの入力に問題がある場合のもう 1 つの解決策として、スクリーン キーボードを使用する方法があります。 

それには、[Start] メニューから [On-Screen Keyboard] を選択するか、タスクバーのショートカットをクリックします。

 

 

元の状態への復帰

 

何らかの理由で操作を間違えた場合や実習ラボを中断した場合は、次の操作を実行して元の状態に戻し、現在のモジュールを最初からやり直してください。

タスクバーの [VMware vSphere PowerCLI] アイコンをクリックして PowerCLI シェル プロンプトを開きます。

 

 

モジュール再開のための仮想マシンのリセット

 

PowerCLI プロンプトで次のように入力します。

.\StopLabVMs.ps1

<Enter> キーを押します。

実行中のすべての仮想マシンが停止してその設定がリセットされ、モジュールを再開できるようになります。

 

 

このモジュールの開始

 

このモジュールを開始しましょう。

タスクバーのショートカットから Chrome を起動します。

 

 

vSphere へのログイン

 

vSphere にログインします。デフォルトのホーム ページは vSphere Web Client です。

何らかの理由でこの認証が機能しない場合は、このチェックボックスをオフにして次の認証情報を使用してください。

ユーザー名: CORP\Administrator
パスワード: VMware1!

 

 

UI の更新

 

この実習ラボでの手動入力を減らすために、多数のタスクがスクリプトで自動化されています。そのため、スクリプトの実行直後は、vSphere Web Client にインベントリの実際の状態が反映されていない可能性があります。

インベントリを手動で更新する必要がある場合は、vSphere Web Client の上部にある [Refresh] アイコンをクリックします。

 

 

[ホストおよびクラスタ] の選択

 

 

vSphere HTML5 Web Client


このモジュールでは、HTML5 バージョンの Web Client を利用することもできます。 このバージョンは即応性と安定性に優れており、同時にセキュリティも確保できるように設計されています。 

現在、Fling リリースでは使用できない機能があります。 最もよく使用するアクションや機能は次のとおりです。

各自の環境でこのクライアントを実行するには、https://labs.vmware.com/flings/vsphere-html5-web-clientを参照してください。

このモジュールで行う操作の大半は HTML5 バージョンでは機能しないため、ご注意ください。ここでは、Flash と HTML5 の両方のインスタンスを同時に開き、切り替えて使用することをおすすめします。

HTML5 Web Client は、[RegionA HTML5 Client] というラベルのブックマーク セクションにあります。


 

HTML5 Web Client のリンク

 

 

 

 

Fling とは

Fling の Web サイト (https://labs.vmware.com/about) から抜粋

VMware のエンジニアは、空き時間に長年温めてきた大量のプロジェクトに取り組んでおり、そのプロジェクト (「Fling」) に関するフィードバックを常に求めています。Fling と名付けられた理由は、Fling には短期間のシリアスではなく楽しい関係という意味があるためです。同様に、ここに用意されているツールは、ご自由に使用して検討していただくことができます。どのツールも、今後の製品サービスに組み込まれる保証はなく、サポートもされません。ただし、完全に無償でダウンロードし、お試しいただくことができます。

 

 

待ち時間感度設定がパフォーマンスに与える影響


このセクションでは、待ち時間感度設定がネットワーク遅延に与える影響を確認します。 このために、ワークロードを開始して仮想マシンに負荷をかけてみましょう。


 

PowerCLI ウィンドウを開く

 

タスクバーの [VMware vSphere PowerCLI] アイコンをクリックしてコマンド プロンプトを開きます。

 

 

CPU ワークロードの開始

 

PowerCLI コンソールから次のように入力します。

.\StartLSLab.ps1

<Enter> キーを押します。

3 台の仮想マシン (03a、05a、06a) が構成されて起動し、その中の 2 台 (05a と 06a) で CPU ワークロードが生成されます。

 

 

VM Stats Collector: CPU 使用の多いワークロードを開始

 

数分してスクリプトが完了したら、2 つの VM Stats Collector アプリケーションが起動します。その後 1 分以内に、それぞれのユーティリティにより CPU 負荷の高いアプリケーションが perf-worker-05a と perf-worker-06a 仮想マシンで起動され、ワークロードのベンチマーク結果が収集されます。これらの仮想マシン perf-worker-05a と perf-worker-06a はホストの CPU に負荷の多い要求をするため、待ち時間感度機能のデモに役立ちます。

重要: 実習ラボ環境の負荷の変化によって、実際の値はスクリーンショットの値と異なる場合があります。

 

 

ESX ホストの選択

 

この実習ラボの実行環境は一定ではありません。そのため、ネストされた ESX ホストの CPU の速度を確認することが重要です。

vSphere Web Client をもう一度開きます。

ホストとクラスタのウィンドウが表示されているはずです。

  1. esx-01a.corp.local を選択します。
  2. プロセッサの CPU 速度をメモします (この場合は 3.07 GHz)。

この情報は、後の手順で使用します。

 

 

perf-worker-04a の編集

 

ここでは、perf-worker-04a 仮想マシンを使用して、待ち時間感度機能を実演します。待ち時間感度が 「高」 の設定のときのネットワーク遅延への影響を見るため、perf-worker-04a で待ち時間感度を 「標準」 に設定した場合と、同じ仮想マシンで待ち時間感度を 「高」 に設定した場合のネットワーク パフォーマンスを比較します。

待ち時間感度機能を 「高」 に設定した場合、2 つの仮想マシン リソースの要件があります。最適なパフォーマンスを得るため、100 % のメモリ予約と 100 % の CPU 予約が必要です。

正しい比較ができるように、「標準」 待ち時間感度の仮想マシンと 「高」 待ち時間感度の仮想マシンでリソース予約を同じにし、2 つの違いが 「高」 待ち時間感度の設定だけになるようにします。

まず、perf-worker-04a 仮想マシンのリソース予約を作成し、待ち時間感度を 「標準」 に設定します。

  1. perf-worker-04a を選択します。 この仮想マシンは esx-02a.corp.local にあります。
  2. [設定の編集] を選択します。

 

 

CPU 予約を最大に設定

 

  1. [CPU] を展開します。
  2. 前の手順でメモした CPU 速度に従って、[予約] の値を可能な限り大きな値に設定します。CPU 速度が 3.1 GHz の場合は、3058 MHz に設定します。

仮想マシンを起動できるようにするには、少し低めの MHz に設定する必要があります。

これにより仮想マシンの CPU 予約がほぼ 100 % に設定されます。仮想マシンの待ち時間感度設定が 「高」 の場合、この CPU 予約により排他的アフィニティが有効になり、物理 CPU の 1 つが 「高」 待ち時間感度の仮想マシンの仮想 CPU 用にのみ予約されます。

通常は予約の値に [Maximum] を選択する必要がありますが、この環境は完全に仮想化されているため、CPU 速度が誤った値で検出されてしまいます。そのため、基盤となるハードウェアに従ってこの値を手動で設定します。

 

 

メモリ予約の設定

 

[Edit Settings] ページでさらに次のようにします。

  1. [CPU] をクリックして [CPU] ビューを折りたたみます。
  2. [メモリ] をクリックして [メモリ] ビューを展開します。
  3. [すべてのゲストメモリを予約 (すべてロック)] チェックボックスをオンにします。

これにより仮想マシンのメモリ予約が 100 % に設定されます。

ここで 「標準」 待ち時間感度の仮想マシンのネットワーク パフォーマンスをテストしますが、後で仮想マシンの待ち時間感度を 「高」 に変更した場合に、メモリ予約が 100 % であることから、仮想マシンが必要とするすべてのメモリは仮想マシンを実行するプロセッサに近い形で配置されます。仮想マシンの待ち時間感度設定を 「高」 に、メモリ予約を 100 % に指定しないと、仮想マシンは起動しません。

 

 

待ち時間感度が 「標準」 であることを確認

 

[設定の編集] ページでさらに次のようにします。

  1. [仮想マシンオプション] タブをクリックします。
  2. [詳細] をクリックしてこのセクションを展開します。
  3. [待ち時間感度] が [標準] であることを確認します。
  4. [OK] をクリックします。

 

 

perf-worker-04a のパワーオン

 

  1. perf-worker-04aを右クリックします。
  2. [電源] を選択します。
  3. [パワーオン] をクリックします。

 

 

esx-02a ホストの CPU 使用率の監視

 

  1. esx-02a.corp.local を選択します。
  2. [監視] を選択します。
  3. [パフォーマンス] を選択します。
  4. [詳細] を選択します。
  5. esx-02a.corp.local の使用率の [Latest] 値がほぼ 100 % であることがわかります。 これは、仮想マシン perf-worker-05a と perf-worker-06a がホストの CPU を可能なだけ消費していることを示します。

待ち時間感度が高い仮想マシンを含む環境は一般的に CPU がアンダーコミットを維持する必要がありますが、CPU に要求を実行することで、「標準」 と 「高」 待ち時間感度のネットワーク パフォーマンスの違いがわかりやすくなります。

仮想マシン perf-worker-03a はネットワーク パフォーマンスのテスト ターゲットの役割を果たします。

 

 

リソース割り当ての監視

 

  1. perf-worker-04a を選択します。
  2. [監視] を選択します。
  3. [使用率] を選択します。

「標準」 待ち時間感度の仮想マシンのリソース割り当てには、総 CPU の一部のみが示され、メモリ予約はアクティブになっています。仮想マシンが起動中は、画面に表示される値が異なる場合があります。

 

 

PuTTY ウィンドウを開く

 

タスクバーの PuTTY アイコンをクリックします。

 

 

perf-worker-04a への SSH 接続

 

  1. perf-worker-04a を選択します。
  2. [Open] をクリックします。

 

 

「標準」 待ち時間感度の仮想マシンのネットワーク遅延のテスト

 

コマンド ラインに次のように入力します。

ping -f -w 1 192.168.100.153

<Enter> キーを押します。

コマンドが完了するのを待って、計 3 回このコマンドを実行します。2 度目と 3 度目は、上矢印キーを押すと前回入力したコマンドを呼び出すことができます。

ping は非常に単純なネットワーク負荷で、ネットワーク パケットをターゲット仮想マシンに送信して仮想マシンに戻る往復時間 (Round Trip Time、RTT) を測定します。esx-02a.corp.local 上の仮想マシン perf-worker-04a は、IP アドレス 192.168.100.153 を使用して esx-01a.corp.local 上の perf-worker-03a に ping を実行します。1 秒間、perf-worker-04a は back-to-back の ping 要求を送信します。要求はカーネルで処理され、オペレーティング システムのアプリケーション層へのアクセスを必要としないことから、ping は理想的な低遅延ネットワーク テストです。

これで 「標準」 待ち時間感度の仮想マシンのネットワーク遅延とスループットのテストは終了です。この PuTTY ウィンドウは後で参照するので閉じないでください。次に仮想マシンを 「高」 待ち時間感度設定に変更します。

 

 

perf-worker-04a 仮想マシンのシャットダウン

 

仮想マシンの待ち時間感度機能を有効にするため、最初に仮想マシンをパワーオフします。仮想マシンがパワーオンの状態でも設定は変更できますが、仮想マシンをパワーオフにして再度パワーオンにするまでは完全に反映されません。

  1. perf-worker-04a を右クリックします。
  2. [電源] を選択します。
  3. [ゲストOSのシャットダウン] をクリックします。

 

 

Confirm Guest Shut Down

 

[はい] をクリックします。

perf-worker-04a がシャットダウンするまで待ちます。

 

 

perf-worker-04a の設定の編集

 

ここでは、perf-worker-04a 仮想マシンを使用して、待ち時間感度機能を実演します。待ち時間感度が 「高」 の設定のときのネットワーク遅延への影響を見るため、この設定を 「標準」 に設定した場合と 「高」 に設定した場合のネットワーク パフォーマンスを比較します。

待ち時間感度機能を 「高」 に設定した場合、2 つの仮想マシン リソースの要件があります。最適なパフォーマンスを得るため、100 % のメモリ予約と 100 % の CPU 予約が必要です。

正しい比較ができるように、「標準」 待ち時間感度の仮想マシンと 「高」 待ち時間感度の仮想マシンでリソース予約を同じにし、2 つの違いが 「高」 待ち時間感度の設定だけになるようにします。

まず、perf-worker-04a 仮想マシンのリソース予約を作成し、待ち時間感度を 「標準」(デフォルト設定) に設定します。

  1. perf-worker-04a をクリックします。
  2. [アクション] をクリックします。
  3. [設定の編集] をクリックします。

 

 

「高」 待ち時間感度の設定

 

  1. [仮想マシンオプション] を選択します
  2. [詳細] を展開します。
  3. [高] を選択します。
  4. [OK] をクリックします。

 

 

CPU 予約の警告

 

前の画像に警告が表示されていることに気付いた方もいるでしょう。待ち時間感度設定の隣に 「Check CPU Reservation」 が表示されています。最適なパフォーマンスを得るため、高待ち時間感度では先に設定したように仮想マシンの CPU 予約を 100 % に設定する必要があります。この警告は、CPU 予約が十分高い値に設定されていても、必ず [Advanced Settings] 画面に表示されます。

予約を設定していない場合でも、仮想マシンはパワーオンが可能で、以降は警告は表示されません。

 

 

perf-worker-04a のパワーオン

 

  1. perf-worker-04a を右クリックします。
  2. [電源] を選択します。
  3. [パワーオン] をクリックします。

 

 

リソース割り当ての監視

 

  1. [監視] タブを選択します。
  2. [使用率] を選択します。

この画像の上半分では、「高」 待ち時間感度の仮想マシン自体はアイドルでありながら、100 % のアクティブ CPU と専用メモリを示しているのがわかります。これを、先に確認した 「標準」 待ち時間感度の仮想マシンのリソース割り当てと比較します。こちらは、総 CPU の一部のみが示され、メモリ予約がアクティブです。アクティブ CPU とメモリの増加は、「高」 待ち時間感度設定によるものとわかります。

この環境では違いがわかりませんが、「高」 待ち時間感度設定で CPU 予約が 100 % に設定されている場合、ホスト CPU は仮想マシンの仮想 CPU をホストする物理コアの使用率 100 % を示します。これは、実習ラボ環境の排他的アフィニティによる通常の結果で、仮想マシン自体がアイドルの場合でも起こります。多くの Intel プロセッサでは、仮想 CPU をホストする物理 CPU は、仮想 CPU がアイドルだとアイドルになります。ただし、この状態でもほかの仮想 CPU に対して使用可能にはなりません。

 

 

VM Stats Collector の監視

 

perf-worker-04a の 「高」 待ち時間感度を設定する前に、CPU ワーカーは同等のベンチマーク スコアを得ています。この時点では、1 つの CPU ワーカーはスコアが低くなります。この例では、perf-worker-06a のスコアが低くなっています。実習ラボ環境では、perf-worker-05a または perf-worker-06a のスコアが低くなります。このことから、perf-worker-04a が perf-worker-06a による CPU サイクルのアクセスに影響を及ぼしており、これにより CPU のベンチマーク スコアが低下していることがわかります。

次に、「高」 待ち時間感度の仮想マシンのネットワーク遅延をテストします。

 

 

PuTTY ウィンドウを開く

 

タスクバーの PuTTY アイコンをクリックします。

 

 

perf-worker-04a への SSH 接続

 

  1. perf-worker-04a を選択します。
  2. [Open] をクリックします。

 

 

「高」 待ち時間感度の仮想マシンのネットワーク遅延のテスト

 

コマンド ラインで次のコマンドを実行します。

ping -f -w 1 192.168.100.153

前回と同様に、コマンドが完了するのを待って、計 3 回このコマンドを実行します。

結果はすぐに見ることができますが、まず待ち時間感度設定をデフォルトに戻しておきます。

 

 

ネットワーク遅延テストの比較

 

タスクバーの PuTTY アイコンをクリックして両方の PuTTY ウィンドウを前面に表示して、標準の待ち時間感度を上に、高待ち時間感度を下に配置します。

ヒント: 両方のウィンドウの下にタイムスタンプがあります。

ルートからのブロードキャスト メッセージ (タイムスタンプ): 最も古いタイムスタンプが標準の待ち時間感度の仮想マシンです。このウィンドウを上にして、ほかを下にします。

それでは、パフォーマンスの結果を詳しく調べてみましょう。

重要: 実習ラボ環境の負荷の変動により、表示される値は表示されているものと異なる場合があります。

実行した ping テストは 1 秒間に可能な限りの ping 要求をリモート仮想マシンに送信しています (「back-to-back の ping」)。1 つの ping が返されると、別の要求が送信されます。ping コマンドはテストごとに 4 つのデータを出力します。

これらのうち、最も注目すべきなのは最小遅延と最大変位です。

「標準」 と 「高」 待ち時間感度の仮想マシンの違いを詳しく見ると、その違いがわかるでしょう。 緑色の枠内の数値に注目してください。「高」 待ち時間感度の仮想マシンのほうが変位が小さいことから、「ジッター」 が少ないことがわかります。これは共有された仮想テスト環境であるため、これらのパフォーマンスの結果は実際の環境の待ち時間感度設定の影響を表すものではありません。あくまでデモ用のものにすぎません。

これらの数値は同じ条件で同じリソース割り当ての同じ仮想マシンから得られたものであることに注意してください。両者の違いは 「標準」 と 「高」 待ち時間感度だけです。

 

 

VM Stats Collector ウィンドウを閉じる

 

タスクバーの .NET アイコンをクリックして、VM Stats Collector を前面に表示します。

以上でネットワークのテストは完了しました。各ウィンドウの X ボタンをクリックしてウィンドウを閉じます。

 

 

開いている PuTTY ウィンドウを閉じる

 

開いている PuTTY ウィンドウを閉じます。

 

まとめとクリーンアップ



 

クリーンアップの手順

この実習ラボの残りの部分を実行できるようにリソースを解放するために、使用した仮想マシンをシャットダウンして構成をリセットする必要があります。

 

 

PowerCLI の起動

 

PowerCLI ウィンドウをまだ開いていない場合は、タスクバーの [VMware vSphere PowerCLI] アイコンをクリックしてコマンド プロンプトを開きます。

 

 

仮想マシンのパワーオフとリセット

 

PowerCLI コンソールで次のように入力します。

.\StopLabVMs.ps1

<Enter> キーを押します。

実行中のすべての仮想マシンが停止してその設定がリセットされます。

 

 

PowerCLI ウィンドウを閉じる

 

PowerCLI ウィンドウを閉じます。

これで別のモジュールに進むことができます。

 

 

要点

待ち時間感度はとても簡単に設定できます。使用するアプリケーションが 「高」 待ち時間感度の条件 (数十マイクロ秒) に適合すると判断した場合は、待ち時間感度を設定してください。

内容を振り返ります。

1. 待ち時間感度が高い仮想マシンに対して、仮想マシンをパワーオフしてメモリ予約を 100 % に設定します。

2. 環境で可能な場合は、待ち時間感度が高い仮想マシンの CPU 予約を 100 % に設定します (予約済みの MHz が仮想マシンの仮想 CPU の周波数合計の 100 % になります)。

3. [Advanced Settings] で待ち時間感度を [High] に設定します。

vSphere で待ち時間感度が高いアプリケーションを実行する方法については、次のホワイトペーパーを参照してください。

http://www.vmware.com/files/pdf/techpaper/VMW-Tuning-Latency-Sensitive-Workloads.pdf 

http://www.vmware.com/files/pdf/techpaper/latency-sensitive-perf-vsphere55.pdf

 

 

まとめ

 

これで、「モジュール X: モジュール タイトル」 は終了です。実習ラボをご利用いただきありがとうございました。 最後にアンケートへのご記入をお願いします。

時間が残っている場合は、この実習ラボに含まれているほかのモジュールが、それぞれの予定所要時間とともに表示されます。 マニュアル内のモジュールにすばやく移動するには、[More Options] - [Table of Contents] の順にクリックします。

 

モジュール 3: CPU パフォーマンス機能: 電力管理ポリシー (15 分)

電力ポリシーの概要と、電力ポリシーがパフォーマンスに与える影響


VMware vSphere は、多様なアプリケーション エコシステムに共通する仮想化プラットフォームとして機能します。アプリケーションごとに異なるパフォーマンス要件を満たす必要がありますが、近年、データセンターの密度とコンピューティングのニーズが高まっているため、これらのアプリケーションを実行するための電力と冷却のキャパシティとコストが圧迫されています。

vSphere のホスト電力管理 (HPM) は、コンピュータ システムやデバイスが非アクティブである場合、または最大パフォーマンスで実行する必要がない場合に、そのシステムやデバイスの特定の部分を省電力状態にすることでエネルギーを節約する機能です。 vSphere では、Advanced Configuration and Power Interface (ACPI) のパフォーマンス状態と電力状態を利用して電力管理を処理します。VMware vSphere 5.0 では、デフォルトの電力管理ポリシーは電圧と周波数の動的な調整 (DVFS) に基づいていました。このテクノロジーでは、プロセッサのパフォーマンス状態を利用して、プロセッサを低周波数、低電圧で実行することで電力を節約できます。しかし、VMware vSphere 5.5 以降のデフォルトの HPM ポリシーでは、DVFS に加えて Deep Halt ステート (C ステート) を使用して、高パフォーマンスを維持しながら電力の節約を以前のリリースに比べて大幅に向上させています。

ただし、ESXi でこれらの機能を制御できるようにするには、サーバの BIOS の電力管理プロファイルが 「OS 制御モード」 かそれと同等のモードに設定されていることを確認する必要があります。

この実習ラボの内容は次のとおりです。

  1. サーバの BIOS 設定をカスタマイズする方法 (スクリーンショットの例を使用)
  2. ESXi に用意されている 4 つの電力ポリシーの概要と、この設定の変更方法
  3. 電力とパフォーマンスのバランスを取るために環境を最適化する方法 (ほとんどの環境に推奨されます)、またはパフォーマンスを最大限に高めるために環境を最適化する方法 (電力の節約が犠牲になる可能性があります)

 

US キーボード以外をご使用のユーザーの方へ

 

US 配列以外のキーボードが接続されたデバイスをご使用の場合は、この実習ラボのモジュールを進める中で CLI コマンドやユーザー名、パスワードが入力しづらいと感じる場合があるかもしれません。

入力する必要のある CLI コマンド、ユーザー名、パスワードは、デスクトップにあるファイル README.txt からコピーしてペーストできます。

 

 

スクリーン キーボード

 

キーボードの入力に問題がある場合のもう 1 つの解決策として、スクリーン キーボードを使用する方法があります。 

それには、[Start] メニューから [On-Screen Keyboard] を選択するか、タスクバーのショートカットをクリックします。

 

 

元の状態への復帰

 

何らかの理由で操作を間違えた場合や実習ラボを中断した場合は、次の操作を実行して元の状態に戻し、現在のモジュールを最初からやり直してください。

タスクバーの [VMware vSphere PowerCLI] アイコンをクリックして PowerCLI シェル プロンプトを開きます。

 

 

モジュール再開のための仮想マシンのリセット

 

PowerCLI プロンプトで次のように入力します。

.\StopLabVMs.ps1

<Enter> キーを押します。

実行中のすべての仮想マシンが停止してその設定がリセットされ、モジュールを再開できるようになります。

 

 

このモジュールの開始

 

このモジュールを開始しましょう。

タスクバーのショートカットから Chrome を起動します。

 

 

vSphere へのログイン

 

vSphere にログインします。デフォルトのホーム ページは vSphere Web Client です。

何らかの理由でこの認証が機能しない場合は、このチェックボックスをオフにして次の認証情報を使用してください。

ユーザー名: CORP\Administrator
パスワード: VMware1!

 

 

UI の更新

 

この実習ラボでの手動入力を減らすために、多数のタスクがスクリプトで自動化されています。そのため、スクリプトの実行直後は、vSphere Web Client にインベントリの実際の状態が反映されていない可能性があります。

インベントリを手動で更新する必要がある場合は、vSphere Web Client の上部にある [Refresh] アイコンをクリックします。

 

 

[Hosts and Clusters] の選択

 

 

サーバの BIOS の電力管理設定の構成


VMware ESXi にはあらゆるホスト電力管理機能が用意されています。 これらの機能によって、ESXi ホストがフル稼動の状態でないときに電力を節約できます。 ハードウェアに用意されている電力管理機能を ESXi で最も柔軟に使用できるようにするために、サーバの BIOS 設定を構成することをおすすめします。また、ESXi 内で電力管理オプションを選択してください(次のセクション)。

ほとんどのシステムで、デフォルト設定は BIOS 制御の電力管理です。この設定では、ESXi は電力を管理できず、代わりに BIOS ファームウェアによって管理されます。 以降のセクションでは、この設定を OS 制御に変更する方法について説明します (ほとんどの環境に推奨されます)。

場合によっては、パフォーマンスの低下が、ESXi またはサーバ ハードウェアで実行されているプロセッサ電力管理と関係していることがあります。 処理速度の遅延の影響を大きく受けるアプリケーションは、プロセッサ電力管理機能が有効になっていると、予想されるパフォーマンスよりも低下することがあります。このようなアプリケーションで最適なパフォーマンスを得るには、ESXi およびサーバ ハードウェアで電力管理機能をオフにする必要があります。 一般に、この設定は BIOS で最大パフォーマンス モードと呼ばれます。

注: 通常、電力管理を無効にすると、特に負荷が低いシステムの場合に消費電力量が増えます。電力管理を行うと、大半のアプリケーションで、パフォーマンスにほとんどまたはまったく影響を与えずに電力を節約することができます。

電力管理はアプリケーションのパフォーマンス低下の原因になっているとテストで判明した場合は無効にしてください。

構成する項目とその構成方法の詳細については、http://www.vmware.com/files/pdf/techpaper/hpm-perf-vsphere55.pdfのホワイトペーパーを参照してください。


 

BIOS を OS 制御モードに設定 (Dell の例)

 

このスクリーンショットは、CPU の省電力機能を OS (ESXi) で直接制御できるように第 11 世代 Dell PowerEdge サーバの BIOS を構成する方法を示しています。

Unified Extensible Firmware Interface (UEFI) を備えた第 12 世代以降の Dell PowerEdge サーバの場合は、[System Setup] - [System BIOS] の設定で [System Profile] のモードを確認します。次のオプションがあります。

[Performance Per Watt (OS)] を選択します。

次に、ESXi で使用される電力管理ポリシーを確認します (次のセクションを参照)。

 

 

BIOS を OS 制御モードに設定 (HP の例)

 

このスクリーンショットは、ROM ベース セットアップ ユーティリティ (RBSU) を使用して HP ProLiant サーバの BIOS を構成する方法を示しています。 赤枠で囲った設定を使用すると、CPU の省電力機能の一部を OS (ESXi) で直接制御できるようになります。

次に、ESXi で使用される電力管理ポリシーを確認します (次のセクションを参照)。

 

 

BIOS を最大パフォーマンス モードに設定 (Dell の例)

 

このスクリーンショットは、電力管理を無効にするように第 11 世代 Dell PowerEdge サーバの BIOS を構成する方法を示しています。

UEFI を備えた第 12 世代以降の Dell PowerEdge サーバの場合は、[System Setup] - [System BIOS] の設定で [System Profile] のモードを確認します。次のオプションがあります。

電力管理を無効にするには [Performance] を選択します。

注: 通常、電力管理を無効にすると、特に負荷が低いシステムの場合に消費電力量が増えます。電力管理を行うと、大半のアプリケーションで、パフォーマンスにほとんどまたはまったく影響を与えずに電力を節約することができます。そのため、電力管理を無効にしてもパフォーマンスが向上しない場合は、消費電力を削減するために電力管理を再度有効にすることをおすすめします。

 

 

BIOS を最大パフォーマンス モードに設定 (HP の例)

 

このスクリーンショットは、電力管理を無効にするためにサーバの RBSU で [HP Power Profile] モードを [Maximum Performance] に設定する方法を示しています。

注: 通常、電力管理を無効にすると、特に負荷が低いシステムの場合に消費電力量が増えます。電力管理を行うと、大半のアプリケーションで、パフォーマンスにほとんどまたはまったく影響を与えずに電力を節約することができます。そのため、電力管理を無効にしてもパフォーマンスが向上しない場合は、消費電力を削減するために電力管理を再度有効にすることをおすすめします。

 

 

BIOS カスタム設定の構成 (上級)

 

このスクリーンショットは、[System Profile] で [Custom] を選択すると個々のパラメータを変更できるということを示しています。 これらの設定の例をいくつか紹介します。詳細については、サーバの BIOS セットアップ マニュアルを参照してください。

 

ESXi でのホスト電力管理の構成


VMware ESXi にはホスト電力管理機能が用意されています。 これらの機能によって、ESXi ホストがフル稼動の状態でないときに電力を節約できます。 ハードウェアに用意されている電力管理機能を ESXi で最も柔軟に使用できるようにするために、サーバの BIOS 設定を構成することをおすすめします。また、ESXi 内で電力管理オプションを選択してください。 このオプションについて説明します。


 

esx-01a のホスト電力管理設定の選択

 

  1. [esx-01a.corp.local] を選択します。
  2. [管理] を選択します。
  3. [設定] を選択します。
  4. ([システム] ではなく) [ハードウェア] セクションで [電力管理] を選択します。

 

 

電力管理ポリシー

 

物理ホストでは、[電力管理] オプションはこのように表示されます (物理ホストのプロセッサによって異なる場合があります)。

ここでは、ホストで認識される ACPI ステートと現在アクティブな電力管理ポリシーを確認できます。 ESXi 5.0、5.1、5.5、6.0、ESXi/ESX 4.1 では 4 つの電力管理ポリシーを使用できます。

  1. [編集] をクリックすると別のオプションが表示されます。

注: この実習ラボ環境の性質上、物理サーバを直接操作しているわけではないため、電力管理ポリシーを変更しても目立った影響は生じません。 そのため、以降のセクションで各電力管理ポリシーについて説明しますが、実際にこの設定を変更することはありません。

 

 

高パフォーマンス

 

[高パフォーマンス] 電力ポリシーを使用するとパフォーマンスが最大限に引き出され、電力管理機能は使用されません。CPU は常に最高レベルの P ステートに保たれます。C ステートは上位 2 つ (実行と停止) のみが使用され、ディープ ステート (最新の Intel プロセッサの C3 や C6 など) は使用されません。[高パフォーマンス] は、5.0 より前のリリースの ESX/ESXi ではデフォルトの電力ポリシーでした。

 

 

バランシング済み(デフォルト)

 

[バランス済み] 電力ポリシーは、パフォーマンスにほとんど影響を与えずにホストの消費電力を削減するように設計されています。このポリシーでは、プロセッサの P ステートを利用するアルゴリズムを使用します。ESXi 5.0 以降ではこの電力ポリシーがデフォルトです。 ESXi 5.5 以降では、[バランス済み] 電力ポリシーでディープ C ステート (C1 よりも深度が深いステート) も使用するようになりました。以前は、アイドル状態の CPU は常に C1 に移行していました。現在は、CPU の起動が次に必要になるタイミングの予測に応じて適切なディープ C ステートが ESXi によって選択されるようになりました。

 

 

低電力

 

[低電力] ポリシーは、パフォーマンス低下のリスクを負いながら P ステートと C ステートの選択アルゴリズムをよりアグレッシブにすることで、[バランシング済み] ポリシーよりも大幅に電力を節約するように設計されています。

 

 

カスタム

 

[カスタム] 電力ポリシーは、ベースは [バランシング済み] と同じですが、個々のパラメータを変更することができます。

[キャンセル] をクリックして、終了します。

次の手順では、[カスタム] 電力ポリシーを制御する設定について説明します。

 

 

カスタム パラメータの設定

 

カスタム ポリシー設定を構成するには、次の手順に従います。

  1. [システムの詳細設定] ([システム] セクション) を選択します。
  2. フィルタ検索バーに 「power」 と入力して (スクリーンショットを参照)、カスタム ポリシー項目と表記のある項目を確認します。

カスタマイズできる設定項目には次のものがあります。

 

まとめ


これで、「モジュール 3: CPU パフォーマンス機能: 電力ポリシー」 は終了です。 実習ラボをご利用いただきありがとうございました。 最後にアンケートへのご記入をお願いします。 重要なポイントと次のステップを確認しましょう。


 

重要なポイント

電力ポリシーをサーバの BIOS レベルで変更する方法と ESXi 自体で変更する方法について説明しました。

まとめると、電力管理ポリシーに関するベスト プラクティスは次のとおりです。

アプリケーションや ESXi ホストの使用率によっては、電力ポリシーを正しく設定するとパフォーマンスとエネルギー消費の両方に大きな影響を与えることができます。最新のハードウェアでは、使用しているハードウェア プラットフォームの電力管理機能を ESXi で制御することができます。事前に定義されたポリシーを使用するか、独自のカスタム ポリシーを作成することができます。

最近の調査によると、ESXi で電力ポリシーを制御することが推奨されます。 詳細については、次の資料を参照してください。

 

 

次のステップ

 

時間が残っている場合は、この実習ラボに含まれているほかのモジュールが、それぞれの予定所要時間とともに表示されます。 マニュアル内のモジュールにすばやく移動するには、[More Options] - [Table of Contents] の順にクリックします。

 

モジュール 4: vSphere Fault Tolerance (FT) とパフォーマンス (30 分)

vSphere FT の概要


VMware vSphere Fault Tolerance (FT) は、サーバ障害時のダウンタイムやデータ損失を排除し、アプリケーションに継続的な可用性を提供する先進的なコンポーネントです。VMware Fault Tolerance は VMware vLockstep テクノロジーを使用して構築されています。VMware Fault Tolerance は、低価格の簡素化された方法で、停止しない VMware vSphere の運用環境と長期にわたる継続稼動を実現します。

vSphere 6 の主な新機能の 1 つに、FT 仮想マシンにおける最大 4 個の仮想 CPU のサポートがあります。これは SMP FT とも呼ばれます。これは、クラスタリング経験が不十分ではあるもののハードウェア障害に関連するダウンタイムを回避する必要がある IT 部門にとって特に重要です。 期末処理など、特定の期間に継続的な保護が必要となるアプリケーションに、vSphere FT を使用できます。


 

vSphere FT の仕組み

 

VMware vSphere Fault Tolerance (FT) では、プライマリ仮想マシンと同期して常に最新の状態に維持される、仮想マシンのライブ 「シャドウ インスタンス」 を作成します。これにより、サーバの障害時でも、アプリケーションを継続的に利用することができます。ハードウェア障害が発生した場合、vSphere FT はフェイルオーバーを自動的に行うため、ダウンタイムの排除とデータ損失の防止が可能になります。

フェイルオーバー後、vSphere FT は新規のセカンダリ仮想マシンを自動的に作成して、アプリケーションを継続的に保護します。

 

 

vSphere FT のアーキテクチャ

vSphere FT は、ストレージ、実行時状態、ネットワーク、透過的なフェイルオーバーの 4 つの基盤となるテクノロジーによって実現されています。

ストレージ

vSphere FT を使用すると、プライマリ仮想マシンとセカンダリ仮想マシンのストレージが常に同期されるようになります。 vSphere FT による保護が開始されると、Storage vMotion を使用して VMDK の最初の同期が行われ、プライマリとセカンダリのディスクの状態がまったく同じになります。

この最初の Storage vMotion は、FT が有効になったとき、フェイルオーバーが発生したとき、パワーオフ状態の FT 仮想マシンがパワーオンされたときに行われます。 FT 仮想マシンは、Storage vMotion が完了するまで FT で保護されているとは見なされません。

この最初の同期の後、vSphere FT は、FT ネットワークを経由してプライマリとセカンダリの間で VMDK の変更をミラーリングして、レプリカのストレージが引き続き同じになるようにします。

実行時状態

vSphere FT を使用すると、2 つのレプリカの実行時状態が常に同じになります。 そのために、vSphere FT では、仮想マシンのアクティブなメモリと正確な稼動状態を継続的にキャプチャし、高速ネットワーク経由で迅速に転送します。これにより、プライマリ ESXi ホストで実行中の仮想マシンをセカンダリ ESXi ホスト上で即座に実行できます。

ネットワーク

仮想マシンで使用されるネットワークは、基盤となる ESXi ホストで仮想化されます。これにより、フェイルオーバー後も仮想マシンの ID とネットワーク接続が維持されます。 vSphere vMotion と同様に、vSphere FT はプロセスの一環として仮想 MAC アドレスを管理します。 セカンダリ仮想マシンがアクティブになると、vSphere FT からネットワーク スイッチに対して ping が送信され、仮想 MAC アドレスに対応する新しい物理アドレスがネットワーク スイッチで認識されているかどうかを確認します。 vSphere FT によってストレージ、正確な稼動状態、ネットワーク ID、アクティブなネットワーク接続が維持されるため、ESXi サーバに障害が発生しても、ダウンタイムの発生やユーザーへの影響はありません。

透過的なフェイルオーバー

vSphere FT を使用すると、フェイルオーバーが発生した場合に、仮想マシンの状態について新しいプライマリと以前のプライマリが常に一致するようになります。 仮想マシンから外部に公開される出力を保持し、2 台の仮想マシンの状態が一貫していることを認める確認応答がセカンダリから返された後にのみ解放することで、このようなことが可能となります (vSphere FT の目的上、外部に公開される出力とはネットワーク上の転送データです)。

 

 

vSphere FT のメリット

vSphere FT のメリットは次のとおりです。

 

 

vSphere 6.0 FT の新機能

 

vSphere 6.0 では、マルチ プロセッサ対応のフォルト トレランス (SMP-FT) が新しく導入されたため、最大 4 個の仮想 CPU を搭載した仮想マシンの可用性を継続的に保護できるようになりました。 また、次の新機能も導入されています。

vSphere の各エディションには違いがあります。Standard では 2 個の仮想 CPU を使用する FT がサポートされ、Enterprise Plus では 4 個の仮想 CPU がサポートされます。

(出典: http://vinfrastructure.it/2015/02/vmware-vsphere-6-the-new-ft-feature/

 

 

vSphere FT を使用した vCenter Server に関する考慮事項

 

vCenter Server を仮想化する際に vSphere FT などのテクノロジーを使用すると、vCenter 管理サーバをハードウェア障害から保護するうえで役立ちます。

vSphere HA と比較すると、vSphere FT では即時の保護を実現できますが、次の制限事項を考慮する必要があります。

vSphere FT は、最大 4 個の仮想 CPU と 64 GB のメモリを使用するワークロードに適しているため、「小規模な」 vCenter Server 環境で使用できます。

 

 

vSphere FT の前提条件

 

vSphere FT が有効になっているすべてのホストで、vSphere FT のログ トラフィックを送信するために 10 Gbps の低遅延の専用 VMkernel インターフェイスが必要です。

次のいずれかの条件に当てはまる場合、vSphere FT を有効にするオプションは使用できません (灰色表示になります)。

次に、仮想マシンで vSphere FT を構成する例について説明します。

 

 

US キーボード以外をご使用のユーザーの方へ

 

US 配列以外のキーボードが接続されたデバイスをご使用の場合は、この実習ラボのモジュールを進める中で CLI コマンドやユーザー名、パスワードが入力しづらいと感じる場合があるかもしれません。

入力する必要のある CLI コマンド、ユーザー名、パスワードは、デスクトップにあるファイル README.txt からコピーしてペーストできます。

 

 

スクリーン キーボード

 

キーボードの入力に問題がある場合のもう 1 つの解決策として、スクリーン キーボードを使用する方法があります。 

それには、[Start] メニューから [On-Screen Keyboard] を選択するか、タスクバーのショートカットをクリックします。

 

 

元の状態への復帰

 

何らかの理由で操作を間違えた場合や実習ラボを中断した場合は、次の操作を実行して元の状態に戻し、現在のモジュールを最初からやり直してください。

タスクバーの [VMware vSphere PowerCLI] アイコンをクリックして PowerCLI シェル プロンプトを開きます。

 

 

モジュール再開のための仮想マシンのリセット

 

PowerCLI プロンプトで次のように入力します。

.\StopLabVMs.ps1

<Enter> キーを押します。

実行中のすべての仮想マシンが停止してその設定がリセットされ、モジュールを再開できるようになります。

 

 

このモジュールの開始

 

このモジュールを開始しましょう。

タスクバーのショートカットから Chrome を起動します。

 

 

vSphere へのログイン

 

vSphere にログインします。デフォルトのホーム ページは vSphere Web Client です。

何らかの理由でこの認証が機能しない場合は、このチェックボックスをオフにして次の認証情報を使用してください。

ユーザー名: CORP\Administrator
パスワード: VMware1!

 

 

UI の更新

 

この実習ラボでの手動入力を減らすために、多数のタスクがスクリプトで自動化されています。そのため、スクリプトの実行直後は、vSphere Web Client にインベントリの実際の状態が反映されていない可能性があります。

インベントリを手動で更新する必要がある場合は、vSphere Web Client の上部にある [Refresh] アイコンをクリックします。

 

 

[ホストおよびクラスタ] の選択

 

 

vSphere HTML5 Web Client


このモジュールでは、HTML5 バージョンの Web Client を利用することもできます。 このバージョンは即応性と安定性に優れており、同時にセキュリティも確保できるように設計されています。 

現在、Fling リリースでは使用できない機能があります。 最もよく使用するアクションや機能は次のとおりです。

各自の環境でこのクライアントを実行するには、https://labs.vmware.com/flings/vsphere-html5-web-clientを参照してください。

このモジュールで行う操作の大半は HTML5 バージョンでは機能しないため、ご注意ください。ここでは、Flash と HTML5 の両方のインスタンスを同時に開き、切り替えて使用することをおすすめします。

HTML5 Web Client は、[RegionA HTML5 Client] というラベルのブックマーク セクションにあります。


 

HTML5 Web Client のリンク

 

 

 

 

Fling とは

Fling の Web サイト (https://labs.vmware.com/about) から抜粋

VMware のエンジニアは、空き時間に長年温めてきた大量のプロジェクトに取り組んでおり、そのプロジェクト (「Fling」) に関するフィードバックを常に求めています。Fling と名付けられた理由は、Fling には短期間のシリアスではなく楽しい関係という意味があるためです。同様に、ここに用意されているツールは、ご自由に使用して検討していただくことができます。どのツールも、今後の製品サービスに組み込まれる保証はなく、サポートもされません。ただし、完全に無償でダウンロードし、お試しいただくことができます。

 

 

実習ラボでの vSphere FT の構成


vSphere FT は既存の vSphere HA クラスタを活用するため、1 つのクラスタ内にある任意の数の仮想マシンを保護できます。 管理者は vSphere Web Client からポイント アンド クリック操作で、特定の仮想マシンの vSphere FT を有効または無効にできます。

この仕組みを 「機能」 の観点から確認するために、ネストされた ESXi 環境である実習ラボ環境を使用します。SMP-FT では、姉妹機能の Uniprocessing Fault Tolerance (UP-FT) と同様に、「記録 / 再生」 機能が使用されなくなっています。代わりに、SMP-FT では新しい高速チェックポイント手法が使用されるようになりました。この手法により、全体的なパフォーマンスが旧バージョンよりも向上しただけでなく、このハンズオン ラボのようなネストされた ESXi 環境で実行する際の追加の構成が大幅に簡素化、削減されました。

注: ネストされた ESXi 環境での SMP-FT の実行は、実際の物理ハードウェアのテストに代わるものではありません。どのようなパフォーマンスのテストであっても、SMP-FT のテストには実際のハードウェアを使用してください。


 

PowerCLI ウィンドウを開く

 

タスクバーの [VMware vSphere PowerCLI] アイコンをクリックしてコマンド プロンプトを開きます。

 

 

vSphere FT の構成の開始

 

PowerCLI コンソールから次のように入力します。

.\StartFaultToleranceLab.ps1

<Enter> キーを押します。

 

 

クラスタの vSphere HA 設定の編集

 

  1. 左側の [ホストおよびクラスタ] リストで [RegionA01-COMP01] をクリックします。
  2. [管理] をクリックします。
  3. [設定] をクリックします。
  4. [vSphere HA] をクリックします (注: スクリーンショットのように、「vSphere HA がオフになっています」 というメッセージが表示されます)。
  5. [編集...] をクリックします。

次に、クラスタで vSphere HA を有効にします。

 

 

vSphere HA の有効化

 

  1. [vSphere HA をオンにする] チェックボックスをオンにします。
  2. [ホストの監視] チェックボックスをオンにします。
  3. [仮想マシンの監視] を [無効] に設定します。
  4. [アドミッションコントロール] をクリックしてこのオプションを構成します。 この設定は次の手順で行います。

 

 

vSphere HA の有効化 (続き)

 

  1. [アドミッションコントロール] で一番下までスクロールし、最後のラジオ ボタン [フェイルオーバ機能を保持しません] を選択します。 実習ラボ環境では HA のすべての制約が必ずしも保証されるわけではないため、この設定が必要です。
  2. [OK] をクリックします。

ダウンタイムを削減するための vSphere HA が有効になりました。 繰り返しになりますが、これは vSphere FT の前提条件です。

 

 

vSphere HA が有効になっていることの確認

 

  1. vSphere HA が有効になったので、vSphere Web Client の上部にある [更新] アイコンをクリックして、これが UI に反映されることを確認します。
  2. [vSphere HA の監視] をクリックします。

 

 

[vSphere HA の監視] ページの確認

 

[監視] セクションの [vSphere HA] タブを確認します。 スクリーンショットのような画面が表示されます。

  1. 問題がないことを確認するために、[構成の問題] をクリックします。

 

 

vSphere HA の構成の問題の確認

 

この [構成の問題] ページを確認します。 vSphere HA に問題がない場合、このリストには何も表示されません。

 

 

perf-worker-02a での vSphere FT の有効化

 

  1. 左側の仮想マシン リストで perf-worker-02a をクリックします。
  2. 右上のペインで [アクション] ドロップダウンをクリックします。
  3. [Fault Tolerance] メニューにカーソルを合わせて [Fault Tolerance をオンにする] を選択します。

次に示す vSphere FT の構成画面が表示されます。

 

 

vSphere FT 用のデータストアの選択 (1/2)

 

まず、セカンダリ仮想マシンの構成ファイル、タイブレーカ ファイル、仮想ハード ディスクのデータストアを選択します。

  1. [参照...] をクリックします。
  2. ドロップダウンで [参照...] をもう一度クリックします。

次に示すデータストアのリストが表示されます。

 

 

vSphere FT 用のデータストアの選択 (2/2)

 

この環境にある唯一のデータストア (RegionA01-ISCSI02-COMP01) をクリックし、[OK] をクリックします。

3 つすべてのファイル ([構成ファイル]、[タイブレーカファイル]、[ハードディスク 1]) について、前の手順とこの手順を繰り返します。

 

 

互換性チェックに成功したことの確認

 

セカンダリ ファイルのデータストアを選択すると、スクリーンショットのような画面が表示され、「互換性チェックは成功しました。」 という緑色のチェック マークが表示されます。

[次へ] をクリックします。

 

 

セカンダリ仮想マシンのホスト esx-02a の選択

 

次に、セカンダリ仮想マシンをホストする場所を選択する必要があります。

  1. perf-worker-02a はすでに esx-01a で実行されているため、クラスタ内の別のホストを選択する必要があります。esx-02a.corp.local をクリックします。
  2. プライマリ仮想マシンとセカンダリ仮想マシンの両方のディスクに対して同じデータストア (RegionA01-ISCI02-COMP01) が使用されるという警告が表示されます。 本番環境には推奨されませんが、これは単なるデモの実習ラボ環境です。 [次へ] をクリックして続行します。

 

 

 

選択内容の確認と vSphere FT の有効化の完了

 

選択内容がこのスクリーンショットと一致することを確認し、[終了] をクリックして、perf-worker-02a に対して FT を有効にします。

 

 

perf-worker-02a のパワーオン

 

  1. 左側の仮想マシン リストで perf-worker-02a をクリックします。 仮想マシンの青色が少し濃くなっていることに注目してください。これはフォルト トレランス仮想マシンになったことを示しています。
  2. 右上のペインで [アクション] リンクをクリックします。
  3. [電源] メニューにカーソルを合わせて [パワーオン] を選択します。

perf-worker-02a 仮想マシンがパワーオンされ、フォルト トレランス仮想マシンへの移行手順が開始されます。

 

 

フォルト トレランス セカンダリ仮想マシンの作成の監視

 

  1. 左上隅にある [vSphere Web Client] テキストをクリックしてホーム画面に戻ります。
  2. 左側のペインで [タスク] をクリックします。
  3. [完了] が表示されるまで [更新] アイコンを何度かクリックして、タスク コンソールの進行状況を監視します。

手順 3 は完了までに最大で 5 ~ 10 分かかる場合があります。 すべてのタスクが [完了] になったら、次の手順に進みます。

 

 

フォルト トレランス仮想マシンの選択

 

前の手順でセカンダリ仮想マシンが作成されたら、perf-worker-02a 仮想マシンをクリックしてフォルト トレランス仮想マシン ビューに戻ります。

 

 

フォルト トレランス仮想マシンになったことの確認

 

perf-worker-02a 仮想マシン ビューから、この仮想マシンがフォルト トレランス仮想マシンになったことを 2 種類の方法で確認できます。

また、[アクション] - [Fault Tolerance] - [フェイルオーバのテスト] の順に選択して、esx-01a から esx-02a へのフェイルオーバーを行うこともできます。 ただし、これによって esx-02a が新しいプライマリ仮想マシンの場所になるだけでなく、esx-01a が新しいセカンダリ仮想マシンの場所になるため、時間もリソースも大量に消費することになります。

 

 

perf-worker-02a での vSphere FT の無効化

 

逆のプロセスを実行して (FT を無効にして)、環境をクリーンアップします。

  1. 右上のペインで [アクション] ドロップダウンをクリックします。
  2. [Fault Tolerance] メニューにカーソルを合わせます。
  3. [Fault Toleranceをオフ] をクリックします。

確認を求めるダイアログ ボックスが表示されます。[はい] をクリックします。

セカンダリ仮想マシンの登録解除、パワーオフ、削除が実行されます。

 

 

[ホストおよびクラスタ] の選択

 

vSphere HA を削除するにはクラスタを再選択する必要があります。

  1. 左上にある [vSphere Web Client] をクリックしてホーム画面に移動します。
  2. [ホストおよびクラスタ] をクリックします。

 

 

クラスタの vSphere HA 設定の編集

 

  1. 左側の [ホストおよびクラスタ] リストで [Cluster Site A] をクリックします。
  2. [管理] をクリックします。
  3. [設定] をクリックします。
  4. [vSphere HA] をクリックします (注: スクリーンショットのように、「vSphere HA がオンになっています というメッセージが表示されます)。
  5. [編集...] をクリックします。

次に、クラスタで vSphere HA を無効にします。

 

 

vSphere HA の無効化

 

  1. [vSphere HAをオン] チェックボックスをオフにします。
  2. [OK] をクリックします。

 

 

perf-worker-02a のシャットダウン

 

  1. 左側の仮想マシン リストで perf-worker-02a をクリックします。 仮想マシンがフォルト トレランス仮想マシンではなくなったため、濃い青色でなくなったことに注目してください。
  2. 右上のペインで [アクション] リンクをクリックします。
  3. [電源] メニューにカーソルを合わせて [ゲストOSのシャットダウン] を選択します。
  4. [はい] をクリックして確認します。

perf-worker-02a 仮想マシンがシャットダウンします。

 

vSphere FT のパフォーマンス


ハンズオン ラボ環境は共有されているため、環境を飽和状態にする可能性があるベンチマークを試行することはできません (ほかのユーザーもこの実習ラボやその他の実習ラボを受講しています)。

そのため、このセクションでは、さまざまなマイクロベンチマークと実際のワークロードを使用した FT のパフォーマンスに関するホワイトペーパーに記載されている結果を紹介します。

すべてのテストで同じハードウェア テスト環境を使用し、同じ仮想マシンで同じワークロードを実行して、FT を有効にした場合と無効にした場合のパフォーマンスを比較しました。


 

カーネル コンパイル

 

このテストは、Linux カーネルの並列コンパイルにかかる時間を示しています。 このワークロードでは、多数の並行プロセスのフォークが原因で、CPU と MMU の両方に高い負荷がかかります。CPU の使用率は 100 % です。このワークロードではディスクの読み書きが実行されますが、ネットワーク トラフィックは生成されません。

この図に示すように、FT による保護を使用すると、カーネル コンパイルにかかる時間は約 7 秒だけ増えます。

 

 

ネットワーク スループット (netperf)

 

netperf は、ネットワーク パケットの送受信のパフォーマンスを測定するマイクロベンチマークです。 FT 使用時の TCP/IP のスループットと遅延のパフォーマンスをデモするために、複数のシナリオとネットワーク速度を使用して構成されています。

この netperf テストでは、一方向の TCP/IP スループットを測定しています。 それぞれの方向でテストを 1 回ずつ実施しており、仮想マシンはデータの受信または送信のいずれかを行っています。 仮想マシン ネットワークの速度はパフォーマンスにおいて重要な要素です。このテストは 1 Gbps アップリンクで行いました。

スループット テストでは、FT による保護の使用時のパフォーマンスについて重要なポイントが明らかになりました。

負荷の高いワークロードの受信では、レプリカの同期を維持する必要があるため、FT トラフィックが増加する傾向があります。 プライマリがデータを受け取ることでレプリカに大きな差異が生じるため、FT ネットワークを経由してさらにデータを送信することが必要になります。 一方、負荷の高いワークロードの送信では、レプリカに差異が生じることはほぼないため、FT トラフィックはごくわずかです。 そのため、Web サーバや読み取り専用のデータベースなどの送信が多いアプリケーションは、FT トラフィックの要件が低くなる傾向があります。

 

 

ネットワーク遅延 (netperf)

 

ネットワークのパフォーマンスで考慮すべきもう 1 つの要素は遅延です。FT を使用するとネットワーク出力に遅延が生じます (この図に示すように、ミリ秒でしか測定できない程度の遅延です)。この遅延が生じるのは、プライマリ仮想マシンがネットワーク パケットを送信する前にセカンダリ仮想マシンが同じ状態になるまで待機する必要があるためです。

このテストでは、netperf を TCP_RR 構成 (単一ストリーム、並列ストリームなし) で実行しており、往復遅延時間が報告されています (往復トランザクション レートの反対)。 TCP_RR は純粋な遅延ベンチマークです。送信元は 1 バイトのメッセージを送信し、1 バイトの応答の待機をブロックします。このベンチマークでは、単位時間で完了したシリアル トランザクションの数がカウントされます (並列化なし)。

純粋な遅延ベンチマークでは、遅延の増加はスループットの低下に比例します。 通常のサーバ アプリケーションは純粋な遅延ベンチマークではありません。アプリケーションでは一度に複数の接続が処理され、各接続は複数のデータ パケットを送信してから、応答を得るために間を置きます。 これにより、実際のアプリケーションでは、スループットを低下させることなくネットワークの遅延を許容することができます。 前の netperf スループット テストはこの一例で、ここで説明したクライアント / サーバ ワークロードも同じことを示しています。

netperf で測定されない要素の 1 つに、ジッターと遅延の変動があります。 FT で保護されている仮想マシンの遅延は、ワークロードによって大幅に変動する可能性があります。また、特定のワークロード内で時間の経過に伴って変動する可能性もあります。 これにより、大きなジッターが生じる場合があります。 使用頻度の高い取引業務用 (HFT) アプリケーションや一部の Voice Over IP (VOIP) アプリケーションなどの待ち時間感度の高いアプリケーションでは、FT を使用することでオーバーヘッドが大きくなる可能性があります。ただし、バルク データが個別のマシンによって送信され、通話管理トラフィックのみが FT で保護されるような音声アプリケーションでは、パフォーマンスに問題は生じません。

 

 

Iometer

 

Iometer は、Microsoft Windows 向けの I/O サブシステムの測定および特性評価ツールです。 ディスクに負荷をかけるさまざまな処理を生成するように設計されています。 このベンチマークでさまざまなタイプのランダム I/O を実行しました。 この棒グラフは、FT で保護されている仮想マシンが保護されていない仮想マシンとほぼ同じスループットを達成していることを示しています。

 

 

Oracle 11g に対する Swingbench

 

このテストでは、Swingbench 2.2 のオーダー エントリ オンライン トランザクション処理 (OLTP) ワークロードを使用して Oracle 11g データベースを動作させました。このワークロードでは、CPU、メモリ、ディスク、ネットワーク リソースといったさまざまな要件が入り交じっています。 FT で保護されている仮想マシンは、FT で保護されていない仮想マシンとほぼ同じスループットを達成できています (上のグラフ)。

基本操作の遅延は、FT による保護の使用時に増加していますが (下のグラフ)、許容可能なミリ秒単位のユーザーしきい値内に収まっています。

 

まとめ


どのフォルト トレランス ソリューションも冗長性に依存しています。 つまり、レプリカを確立してその同期を維持するには、一定のコストを払う必要があります。 このコストは、CPU、ストレージ、ネットワークのオーバーヘッドという形で生じます。FT による保護を使用すると、さまざまなワークロードにおいて、CPU とストレージのオーバーヘッドは一般にわずかまたは最小限になります。FT で保護されている仮想マシンで最も大きなオーバーヘッドは、ネットワーク パケットの遅延の増加です。 ただし、実施したテストによると、FT で保護されているワークロードではネットワーク遅延は増加しますが、アプリケーションのスループットは良好です。ネットワーク遅延によってさまざまなアプリケーションの全体的なスループットが決まるわけではありません。一方、ネットワーク遅延の影響を受けやすいアプリケーション (使用頻度の高い取引業務用ワークロードやリアルタイム ワークロードなど) では、FT による保護の使用時に払うコストが高くなります。

VMware vSphere Fault Tolerance は革新的な新しいテクノロジーです。フォルト トレランス テクノロジーの基本原則と保証を、複数の仮想 CPU を使用するあらゆるワークロードに独自の使いやすい方法で広く適用します。vSphere FT ソリューションは、さまざまなアプリケーションのスループットを向上させることができます。


モジュール 5: メモリ パフォーマンス、基本概念、トラブルシューティング (30 分)

メモリ パフォーマンスのトラブルシューティングの概要


このモジュールでは、仮想化環境のメモリ パフォーマンスの問題を例として紹介しています。 さまざまなパフォーマンス メトリックと設定をチェックして、パフォーマンスの問題を素早く特定する方法も説明しています。

ホストのメモリは限りあるリソースです。VMware vSphere には、ページ共有やリソース割り当て制御、その他のメモリ管理手法を通じて使用可能なメモリを最大限に使用できるようにする高度なメカニズムが組み込まれています。ただし、vSphere のメモリのオーバーコミットメント テクノロジーのいくつかは、ホストのメモリ プレッシャーが発生した場合 (つまり、すべての仮想マシンの仮想メモリの合計が、仮想マシンをホストしている物理ホストのメモリを超える場合) のみ起動されます。

このモジュールでは次の項目について説明します。

このテストでは、vSphere 環境内のメモリ需要と消費されたメモリとを実際に比較します。 また、メモリのオーバーコミットメントがホストと仮想マシンのパフォーマンスにどの程度影響するのかを実際に確認します。

最初に、デモ環境を準備します。


 

US キーボード以外をご使用のユーザーの方へ

 

US 配列以外のキーボードが接続されたデバイスをご使用の場合は、この実習ラボのモジュールを進める中で CLI コマンドやユーザー名、パスワードが入力しづらいと感じる場合があるかもしれません。

入力する必要のある CLI コマンド、ユーザー名、パスワードは、デスクトップにあるファイル README.txt からコピーしてペーストできます。

 

 

スクリーン キーボード

 

キーボードの入力に問題がある場合のもう 1 つの解決策として、スクリーン キーボードを使用する方法があります。 

それには、[Start] メニューから [On-Screen Keyboard] を選択するか、タスクバーのショートカットをクリックします。

 

 

元の状態への復帰

 

何らかの理由で操作を間違えた場合や実習ラボを中断した場合は、次の操作を実行して元の状態に戻し、現在のモジュールを最初からやり直してください。

タスクバーの [VMware vSphere PowerCLI] アイコンをクリックして PowerCLI シェル プロンプトを開きます。

 

 

モジュール再開のための仮想マシンのリセット

 

PowerCLI プロンプトで次のように入力します。

.\StopLabVMs.ps1

<Enter> キーを押します。

実行中のすべての仮想マシンが停止してその設定がリセットされ、モジュールを再開できるようになります。

 

 

このモジュールの開始

 

このモジュールを開始しましょう。

タスクバーのショートカットから Chrome を起動します。

 

 

vSphere へのログイン

 

vSphere にログインします。デフォルトのホーム ページは vSphere Web Client です。

何らかの理由でこの認証が機能しない場合は、このチェックボックスをオフにして次の認証情報を使用してください。

ユーザー名: CORP\Administrator
パスワード: VMware1!

 

 

UI の更新

 

この実習ラボでの手動入力を減らすために、多数のタスクがスクリプトで自動化されています。そのため、スクリプトの実行直後は、vSphere Web Client にインベントリの実際の状態が反映されていない可能性があります。

インベントリを手動で更新する必要がある場合は、vSphere Web Client の上部にある [Refresh] アイコンをクリックします。

 

 

[ホストおよびクラスタ の選択

 

 

vSphere HTML5 Web Client


このモジュールでは、HTML5 バージョンの Web Client を利用することもできます。 このバージョンは即応性と安定性に優れており、同時にセキュリティも確保できるように設計されています。 

現在、Fling リリースでは使用できない機能があります。 最もよく使用するアクションや機能は次のとおりです。

各自の環境でこのクライアントを実行するには、https://labs.vmware.com/flings/vsphere-html5-web-clientを参照してください。

このモジュールで行う操作の大半は HTML5 バージョンでは機能しないため、ご注意ください。ここでは、Flash と HTML5 の両方のインスタンスを同時に開き、切り替えて使用することをおすすめします。

HTML5 Web Client は、[RegionA HTML5 Client] というラベルのブックマーク セクションにあります。


 

HTML5 Web Client のリンク

 

 

 

 

Fling とは

Fling の Web サイト (https://labs.vmware.com/about) から抜粋

VMware のエンジニアは、空き時間に長年温めてきた大量のプロジェクトに取り組んでおり、そのプロジェクト (「Fling」) に関するフィードバックを常に求めています。Fling と名付けられた理由は、Fling には短期間のシリアスではなく楽しい関係という意味があるためです。同様に、ここに用意されているツールは、ご自由に使用して検討していただくことができます。どのツールも、今後の製品サービスに組み込まれる保証はなく、サポートもされません。ただし、完全に無償でダウンロードし、お試しいただくことができます。

 

メモリ リソース制御



 

PowerCLI ウィンドウを開く

 

タスクバーの [VMware vSphere PowerCLI] アイコンをクリックしてコマンド プロンプトを開きます。

 

 

メモリ ワークロードの開始

 

PowerCLI コンソールから次のように入力します。

.\StartMemoryTest.ps1

<Enter> キーを押します。 2 台の仮想マシンが構成されて起動し、メモリ ワークロードが生成されます。

注: 次の手順に示すような出力が表示されるまで数分待ってから、実習ラボを進めてください。

 

 

メモリ アクティビティ ベンチマーク

 

メモリ パフォーマンスのベンチマークを表示する 2 つのウィンドウが起動します。これらのウィンドウは、調査可能なワークロードを生成するために必要となります。これらのウィンドウには、後ですぐに戻ります。

実際のパフォーマンス測定値は環境によって異なります。

 

 

perf-worker-02a の選択

 

vSphere Web Client に戻ります。

  1. perf-worker-02a を選択します。

 

 

perf-worker-02a の使用率メトリックの監視

 

  1. [監視] タブを選択します。
  2. [使用率] を選択します。

perf-worker-02a と perf-worker-03a には 1.5 GB のメモリが構成されており、これらの仮想マシンは ESXi ホスト esx-01a で実行されています。しばらく待つと、仮想マシンのメモリ消費量がこのスクリーンショットのように表示されます。ESXi ホストには 8 GB のメモリがあるため、この時点ではメモリ競合は発生していません。

ホストは、仮想マシンごとの割り当てを、それぞれに割り当てられているシェアの数と最近のワーキング セット サイズの推定値 (このスクリーンショットで [有効なゲストメモリ] と表示されている) に基づいて決定します。

このアプローチにより、アイドル状態のメモリが再利用されている仮想マシンのメモリ使用量が多くなり始めたときに、そのメモリをシェア ベースの最大割り当てまですぐに増加できるようになります。

デフォルトでは、アクティブ メモリの推定値は 60 秒に 1 回特定されます。これを変更するには、Mem.SamplePeriod 詳細設定を調整してください。

 

 

esx-01a ホストの選択

 

  1. esx-01a.corp.local を選択します。

 

 

ESX ホストのメモリ メトリックの表示

 

  1. [監視] を選択します。
  2. [パフォーマンス] を選択します。
  3. [詳細] を選択します。
  4. [メモリ] ビューを選択します。

ホスト上で消費されているメモリは約 4 GB ですが、アクティブなメモリは 3 GB 未満です。ホストには 8 GB のメモリがあるため、メモリ競合は発生していません。

2014 年末頃に、VMware は、ESXi の今後のリリースでは透過的なページ共有 (TPS) がデフォルトで有効にならなくなることを発表しました (ただし、TPS は引き続き利用可能です)。詳細については、http://kb.vmware.com/kb/2080735のナレッジベースの記事を参照してください。

透過的なページ共有 (TPS) とは、メモリ ページの冗長コピーをなくす (重複排除する) 手法です。TPS は、2014 年末頃まではデフォルトで常に実行されていました。最新のハードウェア アシストによるメモリ仮想化システム上で TPS が有効になっている場合、vSphere は、ゲストの物理ページをホストのラージ物理ページ (通常の 4 KB のページではなく連続する 2 MB メモリ領域) とともに優先的に戻してパフォーマンスを向上させます。まったく同じ 2 つのラージ ページが見つかる可能性は極めて低いため、vSphere ではラージ物理ページの共有を試行しません。ホストでメモリ プレッシャーが発生すると、vSphere がラージ メモリ ページを通常の 4 KB のページに分割することがあり、これにより TPS を使用してホストのメモリを統合できるようになります。

vSphere 6 では TPS が強化され、仮想マシン内の共有や仮想マシン間の共有などのさまざまなレベルのページ共有がサポートされるようになりました。詳細については、http://kb.vmware.com/kb/2097593の記事を参照してください。

 

 

アプリケーションのパフォーマンスの観察

 

この環境にはメモリ プレッシャーがないため、仮想マシンのパフォーマンスは良好です。これらの仮想マシンは同一構成であるため、パフォーマンス測定値はほぼ同じです。測定値は実習ラボの設計により若干上下します。

 

 

Memory Hog 仮想マシンのパワーオン

 

perf-worker-04a を選択して右クリックします。

  1. perf-worker-04a を右クリックします。
  2. [電源] を選択します。
  3. [パワーオン] をクリックします。

Perf-worker-04a は、メモリ使用量が多い Memory Hog 仮想マシンとして起動するように構成されています。Memory Hog 仮想マシンには 5.5 GB のメモリが構成されており、ホストの未使用メモリをすべて消費し、メモリ競合を引き起こします。

Memory Hog をパワーオンしている間、perf-worker-02a と perf-worker-03a のメモリ パフォーマンスのベンチマーク スコアを監視します。 メモリ プレッシャーの増加に伴いパフォーマンスが大幅に低下するため、vSphere は環境を安定させなければならなくなります。

 

 

仮想マシンのリソース割り当ての確認

 

1. perf-worker-02a を選択します。

2. [監視] を選択します。

3. [使用率] を選択します。

システム内でメモリ プレッシャーが発生し始めたため、メモリを節約して使用できるよう、vSphere はメモリのオーバーコミットメント技法の使用を開始します。

vCenter Server でメモリ使用率の統計情報が更新されるまで、時間がかかる場合があります。しばらくお待ちください (何も起こらない場合は更新してみてください)。

vSphere が perf-worker 仮想マシンに対して何らかのメモリのオーバーコミットメント技法を使用してメモリ プレッシャーを緩和したことを確認してください。仮想マシンに消費されたメモリが、メモリ プレッシャーの適用前より減少していることを確認してください。 仮想マシンに必要なアクティブ メモリを物理メモリ上に保持している限り、アプリケーションのパフォーマンスは良好です。

 

 

esx-01a.corp.local の選択

 

  1. esx-01a.corp.local を選択します。

 

 

ESX ホストのメモリ メトリックの確認

 

Memory Hog をパワーオンしてあるので、ESX ホストのメモリ メトリックを確認します。

  1. [監視] を選択します。
  2. [監視] を選択します。
  3. [詳細] を選択します。
  4. [メモリ] を選択します。

[与えられたメモリ] と [消費] の値が ESX ホストの最大容量 (8 GB) に非常に近く、[有効] は増えているものの、[消費] より依然として少ないことを確認します。また、ホストでメモリ プレッシャーを増やしたときに、スワップとバルーニングが開始されたことも確認できます。[スワップで使用されているメモリ] が比較的低いことも確認します。 アクティブ スワッピングはパフォーマンス上の懸念事項ですが、このメトリックだけに頼ると判断ミスをしかねません。スワッピングがパフォーマンスに影響を与えているかどうかをより正確に判断するには、次に説明する [チャートオプション] 画面から使用できる [スワップイン速度] を見る必要があります。[スワップイン速度] がある程度の値を示す場合は、パフォーマンスの問題が発生している可能性があります。

 

 

[チャートオプション] の選択

 

[スワップイン速度] を調べてみましょう。

 

 

[スワップイン速度] カウンタの選択

 

  1. 下にスクロールして [スワップイン速度] を見つけます。
  2. [スワップイン速度] を選択します。
  3. [OK] をクリックします。

 

 

[スワップイン速度] グラフの監視

 

[スワップイン速度] は紫色のグラフです。これは前のグラフとは異なる点です。

このスクリーンショットに示されている範囲では、グラフの進行を待つ必要はありません。そのままにしておいて、後の手順で perf-worker-04a を停止する前に、この画面に戻って結果を確認します。

メモリを過剰に割り当てることは、ほとんどのアプリケーションと環境において問題にならないことが多いといえます。一般的に、メモリを 20 % 過剰に割り当てても安全であるため、最初のサイズ設定では、20 % 以下からメモリの過剰割り当てを開始して、アプリケーションのパフォーマンスを監視した後に割り当て量を増減し、メモリの過剰割り当てによって一定のスワップイン率を引き起こさないかどうか確認します。これは、透過的なページ共有を使用しているかどうかにも左右されます。

ご覧のように、ESXi ホストでは大量のメモリ スワップインが発生しています。

続いて、これがメモリ パフォーマンスの測定値にどのような影響を与えているかを確認します。

 

 

競合発生時のメモリ パフォーマンスの監視

 

esx-01a.corp.local にメモリ競合を適用したので、メモリ パフォーマンスは大幅に低下しています。これらの仮想マシンのパフォーマンスはほぼ同じです。

パフォーマンス測定値が高いままの場合は、数分待つと大幅に低下します。

ベンチマークを長期にわたって監視すると、パフォーマンスが変動します。これは、仮想マシンでメモリをアクティブのままにするベンチマークのためです。これにより、スワップインとスワップアウトの 「波」 が生じ、パフォーマンス測定値が変化します。ESXi によってパワーオン状態の仮想マシン間のメモリ アクセスが最適化されると、アプリケーションのパフォーマンスは向上し始めます。パフォーマンスは、メモリ競合の適用前と同じレベルまで向上する可能性があります。すべてはメモリ競合のレベル、メモリ アクティビティのレベル、利用可能なメモリのオーバーコミットメント技法に左右されます。

仮想マシンによるメモリ アクセスの優先度を変更してみましょう。

 

 

perf-worker-03a の編集

 

  1. perf-worker-03a を選択して右クリックします。
  2. [設定の編集...] をクリックします。

 

 

メモリ シェアを 「高」 に変更

 

  1. [仮想ハードウェア] を選択します。
  2. [メモリ] を展開します。
  3. [シェア] で [高] を選択します。
  4. [OK] をクリックします。

 

 

シェアが 「高」 の場合のメモリ パフォーマンスの監視

 

数分待つと、perf-worker-03a のパフォーマンスが向上し始めます。

perf-worker-03a に割り当てられるメモリ シェアの量を 2 倍に増やしたので、この仮想マシンは perf-worker-02a と perf-worker-04a よりも優先されています。これにより、perf-worker-03a のメモリ パフォーマンスが向上します。

シェアは、仮想マシン間でリソースへのアクセスの優先度を決定する際に影響する手法ですが、リソースの競合時にのみ影響します。使用率の低い環境で仮想マシンのパフォーマンスを向上させることはありません。

perf-worker-03a にシェアを多く割り当てたままで、メモリ競合を削除してみましょう。

 

 

perf-worker-04a のパワーオフ

 

  1. perf-worker-04a を右クリックします。
  2. [電源] を選択します。
  3. [パワーオフ] をクリックします。

 

 

Confirm Power Off

 

 

 

メモリ パフォーマンスの観察

 

ここで数分間、アプリケーションのパフォーマンスを監視します。Memory Hog 仮想マシンをパワーオフしたため、メモリ競合がなくなり、メモリ パフォーマンスが Memory Hog をパワーオンする前と同じレベルに戻ります。そのため、perf-worker-03a に割り当てられるシェアの量は重要ではなくなっています。

 

 

ベンチマーク ウィンドウを閉じる

 

  1. 2 つのパフォーマンス カウンタを閉じます。

 

まとめとクリーンアップ



 

クリーンアップの手順

この実習ラボの残りの部分を実行できるようにリソースを解放するために、使用した仮想マシンをシャットダウンして構成をリセットする必要があります。

 

 

PowerCLI の起動

 

PowerCLI ウィンドウをまだ開いていない場合は、タスクバーの [VMware vSphere PowerCLI] アイコンをクリックしてコマンド プロンプトを開きます。

 

 

仮想マシンのパワーオフとリセット

 

PowerCLI コンソールで次のように入力します。

.\StopLabVMs.ps1

<Enter> キーを押します。

実行中のすべての仮想マシンが停止してその設定がリセットされます。

 

 

PowerCLI ウィンドウを閉じる

 

PowerCLI ウィンドウを閉じます。

これで別のモジュールに進むことができます。

 

 

要点

この実習ラボでは、メモリのオーバーコミットメントがパフォーマンスに与える影響と、vSphere で複数の手法を使用してメモリのオーバーコミットメントの影響を低減する方法について説明しました。また、TPS のセキュリティをどのように評価するかに応じて、ESXi で仮想マシン内の TPS や仮想マシン間の TPS を使用するかまったく使用しないかを調整する方法についても説明しました。ESXi のメモリのオーバーコミットメント技法である程度のメモリのオーバーコミットメントを調整することはできますが、可能であれば、仮想マシンの構成を適切にサイジングすることをおすすめします。仮想マシンのリソース構成を適切にサイジングする方法のインスピレーションを得るには、HOL-SDC-1610 モジュール 5 を参照してください。このモジュールでは、vRealize Operations Manager を使用してリソースの負荷を特定し、適切なサイジングを行います。

 

 

まとめ

 

これで、「モジュール 5: メモリ パフォーマンス、基本概念、トラブルシューティング」 は終了です。実習ラボをご利用いただきありがとうございました。 最後にアンケートへのご記入をお願いします。

時間が残っている場合は、この実習ラボに含まれているほかのモジュールが、それぞれの予定所要時間とともに表示されます。 マニュアル内のモジュールにすばやく移動するには、[More Options] - [Table of Contents] の順にクリックします。

 

モジュール 6: メモリ パフォーマンス機能: メモリのホット アドを使用した仮想 NUMA (30 分)

NUMA と仮想 NUMA の概要


5.0 以降の vSphere は、ゲスト OS で物理 NUMA トポロジーが認識されるようにする仮想 NUMA 機能を備えています。従来は、仮想マシンのサイズや基盤となるハードウェアに関係なく、仮想マシンでは単一の NUMA ノードが認識されていました。仮想化されるワークロードのサイズはますます大きくなっており、ゲスト OS とアプリケーションがアプリケーション プロセスの実行場所や特定のアプリケーション メモリの配置場所を決定できることもますます重要になっています。ESXi は NUMA に対応しているため、可能な限り、常に仮想マシンを単一の NUMA ノード内に収めようとします。「大規模な仮想マシン」 の登場により、必ずしも単一ノード内に収まるとは限らなくなっています。

実習ラボ環境は完全に仮想化されているため、仮想マシンで認識される NUMA アーキテクチャを適用する必要があります。実際の環境では物理アーキテクチャを確認できます。このモジュールでは、仮想 NUMA の単独での動作と、ソケットあたりのコア数機能と組み合わせて使用する場合の動作について説明します。


 

NUMA

 

Non-Uniform Memory Access (NUMA) システム アーキテクチャ

各ノードは CPU コアとメモリで構成されます。物理 CPU は複数の NUMA ノードにまたがってメモリにアクセスできますが、パフォーマンスが犠牲になり、メモリ アクセス時間が 30 ~ 100 % 長くなる可能性があります。

 

 

 

仮想 NUMA を利用しない場合

 

この例では、12 個の仮想 CPU を搭載した仮想マシンが、それぞれ 6 コアを備えた 4 つの NUMA ノードがあるホストで実行されています。この仮想マシンでは物理 NUMA 構成が認識されていないため、ゲスト OS とアプリケーションでは単一の NUMA ノードのみが認識されます。つまり、ゲストはプロセスとメモリを物理 NUMA ノード内に配置できません。

メモリの局所性は低くなります。

 

 

仮想 NUMA を利用する場合

 

この例では、12 個の仮想 CPU を搭載した仮想マシンが、それぞれ 6 コアを備えた 4 つの NUMA ノードがあるホストで実行されています。この仮想マシンでは物理 NUMA 構成が認識されているため、ゲスト OS とアプリケーションでは 2 つの NUMA ノードが認識されます。つまり、可能な限り、ゲストはプロセスとそれに伴うメモリを物理 NUMA ノード内に配置できます。

メモリの局所性は高くなります。

 

 

US キーボード以外をご使用のユーザーの方へ

 

US 配列以外のキーボードが接続されたデバイスをご使用の場合は、この実習ラボのモジュールを進める中で CLI コマンドやユーザー名、パスワードが入力しづらいと感じる場合があるかもしれません。

入力する必要のある CLI コマンド、ユーザー名、パスワードは、デスクトップにあるファイル README.txt からコピーしてペーストできます。

 

 

スクリーン キーボード

 

キーボードの入力に問題がある場合のもう 1 つの解決策として、スクリーン キーボードを使用する方法があります。 

それには、[Start] メニューから [On-Screen Keyboard] を選択するか、タスクバーのショートカットをクリックします。

 

 

元の状態への復帰

 

何らかの理由で操作を間違えた場合や実習ラボを中断した場合は、次の操作を実行して元の状態に戻し、現在のモジュールを最初からやり直してください。

タスクバーの [VMware vSphere PowerCLI] アイコンをクリックして PowerCLI シェル プロンプトを開きます。

 

 

モジュール再開のための仮想マシンのリセット

 

PowerCLI プロンプトで次のように入力します。

.\StopLabVMs.ps1

<Enter> キーを押します。

実行中のすべての仮想マシンが停止してその設定がリセットされ、モジュールを再開できるようになります。

 

 

このモジュールの開始

 

このモジュールを開始しましょう。

タスクバーのショートカットから Chrome を起動します。

 

 

vSphere へのログイン

 

vSphere にログインします。デフォルトのホーム ページは vSphere Web Client です。

何らかの理由でこの認証が機能しない場合は、このチェックボックスをオフにして次の認証情報を使用してください。

ユーザー名: CORP\Administrator
パスワード: VMware1!

 

 

UI の更新

 

この実習ラボでの手動入力を減らすために、多数のタスクがスクリプトで自動化されています。そのため、スクリプトの実行直後は、vSphere Web Client にインベントリの実際の状態が反映されていない可能性があります。

インベントリを手動で更新する必要がある場合は、vSphere Web Client の上部にある [Refresh] アイコンをクリックします。

 

 

[ホストおよびクラスタ] の選択

 

 

vSphere HTML5 Web Client


このモジュールでは、HTML5 バージョンの Web Client を利用することもできます。 このバージョンは即応性と安定性に優れており、同時にセキュリティも確保できるように設計されています。 

現在、Fling リリースでは使用できない機能があります。 最もよく使用するアクションや機能は次のとおりです。

各自の環境でこのクライアントを実行するには、https://labs.vmware.com/flings/vsphere-html5-web-clientを参照してください。

このモジュールで行う操作の大半は HTML5 バージョンでは機能しないため、ご注意ください。ここでは、Flash と HTML5 の両方のインスタンスを同時に開き、切り替えて使用することをおすすめします。

HTML5 Web Client は、[RegionA HTML5 Client] というラベルのブックマーク セクションにあります。


 

HTML5 Web Client のリンク

 

 

 

 

Fling とは

Fling の Web サイト (https://labs.vmware.com/about) から抜粋

VMware のエンジニアは、空き時間に長年温めてきた大量のプロジェクトに取り組んでおり、そのプロジェクト (「Fling」) に関するフィードバックを常に求めています。Fling と名付けられた理由は、Fling には短期間のシリアスではなく楽しい関係という意味があるためです。同様に、ここに用意されているツールは、ご自由に使用して検討していただくことができます。どのツールも、今後の製品サービスに組み込まれる保証はなく、サポートもされません。ただし、完全に無償でダウンロードし、お試しいただくことができます。

 

仮想 NUMA とソケットあたりのコア数


仮想マシンで仮想 NUMA アーキテクチャが認識されるようにできるだけでなく、仮想マシンにおけるソケットあたりのコア数を変更することもできます。この機能では、ゲスト OS で仮想 CPU がどのように認識されるかを制御します。VMware はデフォルトで複数のシングルコア CPU を提供するため、ゲスト OS は実質的にマルチコア CPU を 「認識」 できるようになります。

一般に、デフォルト (仮想ソケットあたりのコア数 1) をそのまま使用して、仮想コアの数をワークロードで必要とされるサイズに設定することが推奨されます。これは、複数の仮想マルチコア CPU を使用してもパフォーマンスが向上しないためです。 この機能の主な用途は、アプリケーションで必要になる仮想ソケットが少ない場合のライセンス管理です。 この場合、仮想 NUMA の最適なサイズを特定し、仮想ソケット数を同じ値に設定する必要があります。


 

PowerCLI ウィンドウを開く

 

タスクバーの [VMware vSphere PowerCLI] アイコンをクリックしてコマンド プロンプトを開きます。

 

 

仮想 NUMA スクリプトの起動

 

PowerCLI コンソールから次のように入力します。

.\StartvNUMA.ps1

<Enter> キーを押します。

メモリのホット アドが有効になっている、4 個の仮想 CPU を搭載した仮想マシンが構成され、起動します。

次に、perf-worker-01a 仮想マシンへのリモート デスクトップ セッションが開始されます。

 

 

perf-worker-01a でコマンド プロンプトを開く

 

perf-worker-01a へのリモート デスクトップ ウィンドウで、cmd.exe を起動します。

  1. [Start] ボタンをクリックします。
  2. cmd.exe をクリックします。

注: この手順は必ずリモート デスクトップ接続ウィンドウ内で実行してください (スクリーンショットを参照)。

 

 

デフォルトのコア数またはソケット数と NUMA アーキテクチャの確認

 

次のコマンドを入力し、<Enter> キーを押します。

coreinfo -c -n -s

出力から、仮想マシンで以下が認識されていることがわかります。

  1. 4 コアと同等の 4 つの物理プロセッサ (実際は仮想)(仮想ソケットあたりのコア数 1 というデフォルトを使用して構成されているため)
  2. 4 つの論理プロセッサ (物理ソケットあたり 1 つ)
  3. 1 つの NUMA ノード

それでは、ソケットあたりのコア数を変更するとこの出力にどのような影響が生じるかを見てみましょう。

 

 

perf-worker-01a のシャットダウン

 

メイン コンソールの vSphere Web Client に戻ります。

  1. perf-worker-01a を右クリックします。
  2. [電源] を選択します。
  3. [ゲストOSのシャットダウン] を選択します。

 

 

シャットダウンの確認

 

[はい] をクリックして操作を確定します。

 

 

perf-worker-01a の設定の編集

 

  1. 左側の仮想マシン リストから perf-worker-01a を選択します。
  2. [アクション] をクリックします。
  3. [設定の編集...] をクリックします。

 

 

CPU 構成の変更

 

  1. [仮想ハードウェア] タブを選択します。
  2. [CPU] を展開します。
  3. [ソケットごとのコア] ドロップダウンで [2] を選択します。
  4. [OK] をクリックします。

 

 

perf-worker-01a 仮想マシンのパワーオン

 

  1. perf-worker-01a を右クリックします。
  2. [電源] を選択します。
  3. [パワーオン] をクリックします。

 

 

perf-worker-01a へのリモート デスクトップ セッションの開始

 

仮想マシンが起動するまで待ってから、デスクトップ上の 01a ショートカットをダブルクリックして perf-worker-01a へのリモート デスクトップ接続を開きます。

 

 

perf-worker-01a でコマンド プロンプトを開く

 

perf-worker-01a ウィンドウで、コマンド プロンプトを起動します。

  1. [Start] ボタンをクリックします。
  2. cmd.exe をクリックします。

注: この手順は必ずリモート デスクトップ接続ウィンドウ内で実行してください (スクリーンショットを参照)。

 

 

coreinfo を使用した、ソケットあたりのコア数が複数であることの確認

 

次のコマンドを入力し、<Enter> キーを押します。

coreinfo -c -n -s

出力から、1 つ変化した点があることがわかります。仮想マシンでソケットあたり 2 つの論理プロセッサ (コア) が認識されるようになっています。 プロセッサ (コア) は 4 つのままで、すべてが単一の NUMA ノード内で認識されているため、これは単にゲスト OS での認識の問題であり、パフォーマンスには影響しません。この機能は、ライセンス条件に従うために使用できます。

これは仮想 NUMA が無効になっている場合に有効になります。ソケットあたりのコア数が 2 であるこの構成を使用して仮想 NUMA を有効にするとどうなるかを見てみましょう。

 

 

perf-worker-01a のシャットダウン

 

メイン コンソールの vSphere Web Client に戻ります。

  1. perf-worker-01a を右クリックします。
  2. [電源] を選択します。
  3. [ゲストOSのシャットダウン] を選択します。

 

 

シャットダウンの確認

 

[はい] をクリックして操作を確定します。

 

 

perf-worker-01a の設定の編集

 

  1. 左側の仮想マシン リストから perf-worker-01a を選択します。
  2. [アクション] をクリックします。
  3. [設定の編集...] をクリックします。

 

 

詳細構成パラメータの編集

 

  1. [仮想マシンのオプション] タブを選択します。
  2. [詳細] を展開します。
  3. [構成の編集...] をクリックします。

 

 

仮想 NUMA を有効にするためのしきい値の減少

 

  1. [名前] 列をクリックして、構成パラメータをアルファベット順に並び替えます。
  2. 行 numa.vcpu.min を見つけて値を 4 に変更します (スクリーンショットを参照)。デフォルトは 9 です。
  3. [OK] を 2 回クリックしてこの変更を保存します。

numa.vcpu.min 構成パラメータは、仮想 NUMA を有効にするための仮想マシンにおける仮想 CPU の最低限の数を指定します。 デフォルトは 9 であり、この場合に仮想 NUMA を有効にするには、仮想マシンに 9 個以上の仮想 CPU が必要になります。

この値を 4 に減らすことで、リソースに制限のある実習ラボ環境で仮想 CPU の数を増やすことなく、仮想 NUMA がこの仮想マシンにどのような影響を与えるかを確認できます。

 

 

perf-worker-01a 仮想マシンのパワーオン

 

  1. perf-worker-01a を右クリックします。
  2. [電源] を選択します。
  3. [パワーオン] をクリックします。

 

 

perf-worker-01a へのリモート デスクトップ セッションの開始

 

仮想マシンが起動するまで待ってから、デスクトップ上の 01a ショートカットをダブルクリックして perf-worker-01a へのリモート デスクトップ接続を開きます。

 

 

perf-worker-01a でコマンド プロンプトを開く

 

perf-worker-01a ウィンドウで、コマンド プロンプトを起動します。

  1. [Start] ボタンをクリックします。
  2. cmd.exe をクリックします。

注: この手順は必ずリモート デスクトップ接続ウィンドウ内で実行してください (スクリーンショットを参照)。

 

 

複数の仮想 NUMA ノードがあることの確認

 

次のコマンドを入力し、<Enter> キーを押します。

coreinfo -c -n -s

出力から、仮想マシンでそれぞれが 2 つのプロセッサを持つ 2 つの仮想 NUMA ノードが認識されるようになったことがわかります。これは、この仮想マシンで仮想 NUMA が正常に有効になっていることを意味します。

このモジュールですでに確認したように、ソケットあたりのコア数を変更するだけでは、仮想マシンで認識される NUMA アーキテクチャは変更されません。ソケットあたりのコア数の構成と仮想 NUMA を組み合わせて使用することで、認識される仮想 NUMA アーキテクチャが適用されることがわかりました。つまり、仮想 CPU が 8 個 (デフォルト値) を超える仮想マシンでソケットあたりのコア数機能を使用すると、仮想マシンで認識される仮想 NUMA アーキテクチャが適用されるため、仮想マシンのパフォーマンスが影響を受ける可能性があります。これは、仮想マシンが不必要に複数の NUMA ノードにまたがるように強制される可能性があるためです。

 

 

仮想 NUMA とソケットあたりのコア数に関するベスト プラクティス

一般に、仮想 NUMA とソケットあたりのコア数については次のベスト プラクティスに従ってください。

仮想 NUMA には多数の詳細属性があります (一覧については、vSphere ドキュメント センターを参照してください)。一部を次に示します。

 

メモリのホット アドを使用した仮想 NUMA


vSphere リリース 5.0 ~ 5.5 では、仮想 NUMA がメモリのホット アドと組み合わせて構成されている場合、追加のメモリは NUMA ノード 0 にのみ割り当てられていました。vSphere 6 では、追加のメモリは利用可能なすべての NUMA ノードに均等に配分されるため、仮想マシンのメモリのスケーラビリティが向上しています。

仮想 CPU のホットプラグが有効になっている場合、仮想 NUMA は無効のままになるため、仮想 CPU のホットプラグは使用する場合にのみ有効にしてください。詳細については、http://kb.vmware.com/kb/2040375の記事を参照してください。


 

NumaExplorer の起動

 

perf-worker-01a がすでに実行されており、その仮想マシンへのアクティブな RDP セッションを開始している必要があります。開始していない場合は、このモジュールですでに説明したように、perf-worker-01a をパワーオンしてメイン コンソール上のショートカットから RDP セッションを開始します。

perf-worker-01a で次の手順を実行します。

  1. [Start] をクリックします。
  2. NumaExplorer をクリックします。

 

 

仮想 NUMA のメモリ サイズの確認

 

  1. [Refresh] ボタンを数回クリックして、GetNumaAvailableMemory の値が少し変化するのを確認します。

ご覧のように、仮想マシンには引き続き 2 つの NUMA ノードがあり、それぞれが 2 つのプロセッサ コアを備えています。 また、実行中のプロセスのメモリ消費を考慮して、使用可能なメモリが 2 つのノードに均等に配分されていることもわかります。

 

 

perf-worker-01a の設定の編集

 

  1. 左側の仮想マシン リストから perf-worker-01a を選択します。
  2. [アクション をクリックします。
  3. [設定の編集...] をクリックします。

 

 

メモリ構成の変更

 

  1. [仮想ハードウェア] タブを選択します。
  2. [メモリ] を 「4096 MB」 に変更します。
  3. [OK] をクリックします。

 

 

仮想 NUMA のメモリ サイズの確認

 

perf-worker-01a のリモート デスクトップ接続ウィンドウをクリックして再度表示します。

  1. [Refresh] ボタンをもう一度クリックして、GetNumaAvailableMemory が 1 つの NUMA ノードにつき 1 GB 増加していることを確認します (合計 2 GB を追加)。

このテストから、仮想 NUMA が有効になっている仮想マシンで、メモリのホット アドによって追加のメモリが仮想 NUMA ノードに均等に配分されていることがわかります。

 

 

perf-worker-01a へのリモート デスクトップ接続の終了

 

  1. リモート デスクトップ接続ウィンドウを閉じます (スクリーンショットを参照)。

 

まとめとクリーンアップ



 

クリーンアップの手順

この実習ラボの残りの部分を実行できるようにリソースを解放するために、使用した仮想マシンをシャットダウンして構成をリセットする必要があります。

 

 

PowerCLI の起動

 

PowerCLI ウィンドウをまだ開いていない場合は、タスクバーの [VMware vSphere PowerCLI] アイコンをクリックしてコマンド プロンプトを開きます。

 

 

仮想マシンのパワーオフとリセット

 

PowerCLI コンソールで次のように入力します。

.\StopLabVMs.ps1

<Enter> キーを押します。

実行中のすべての仮想マシンが停止してその設定がリセットされます。

 

 

PowerCLI ウィンドウを閉じる

 

PowerCLI ウィンドウを閉じます。

これで別のモジュールに進むことができます。

 

 

要点

この実習ラボでは、仮想 CPU が 8 個以下の仮想マシンでは仮想 NUMA はデフォルトで有効にならないことについて説明しました。 このシナリオでは、仮想マシンは構成に関係なく物理 NUMA ノード内に収まるため、(ゲストにマルチコア CPU を認識させるために) ソケットあたりのコア数をデフォルトの 1 から増やしてもパフォーマンスには影響しません。  その場合、ソケットあたりのコア数設定はライセンスの問題にのみ使用されます。

ただし、仮想 NUMA を使用する場合、ソケットあたりのコア数設定はゲストで認識される仮想 NUMA トポロジーに影響し、このトポロジーが物理 NUMA トポロジーと一致しない場合はパフォーマンスにも影響する可能性があります。  デフォルトでは、ソケットあたりのコア数を手動で増やしていない限り、仮想 NUMA によって最適なトポロジーが選択されます。  この数をライセンスの都合で変更している場合は、手動で物理 NUMA トポロジーと一致させることが重要です。

警告: ソケットあたりのコア数の構成と仮想 NUMA を組み合わせて使用する場合は、変更を行う際に注意が必要となります。基盤となる NUMA アーキテクチャと一致しないか、少なくとも基盤となる NUMA アーキテクチャ内に収まらない仮想マシンの NUMA アーキテクチャを適用すると、要求の厳しいアプリケーションの場合にパフォーマンスの問題が発生する可能性があります。ただし、これは、異なる物理 NUMA レイアウトが含まれているクラスタ内の物理サーバの NUMA レイアウトと一致するように仮想マシンの NUMA アーキテクチャを管理するためにも使用できます。仮想マシンの仮想 NUMA 構成は、その仮想マシンを初めてパワーオンしたときにロックされ、(デフォルトでは) その後変更されません。これは、ゲスト OS とアプリケーションの安定性を確保するためです。

まとめると、仮想 NUMA が有効になっている仮想マシンを使用する場合は、仮想マシンの仮想 NUMA レイアウトがクラスタ内のすべてのホストの物理 NUMA アーキテクチャと一致していることを確認する必要があります。

NUMA ノードは CPU コアとメモリで構成されます。そのため、仮想マシンのメモリが単一の NUMA ノード内に収まらない場合に、その仮想マシンの仮想 CPU が 8 個以下のときは、ゲスト OS が仮想 CPU とメモリをより適切に配置できるようにするために、仮想 NUMA を有効にすることをおすすめします。

仮想マシンのソケットあたりのコア数の設定がパフォーマンスに与える影響と仮想 NUMA の実際の動作は、混乱を招く内容となっています。このモジュールを通じて、次のことを説明しました。

  1. 仮想 NUMA を利用しない仮想マシンでソケットあたりのコア数を設定しても、パフォーマンスには影響しません。この設定はライセンス制限に準拠するためだけに使用されます。
  2. 仮想 NUMA が有効になっている仮想マシンでソケットあたりのコア数を設定すると、パフォーマンスに影響する可能性があります。この設定は特定の仮想 NUMA アーキテクチャを強制するために使用できます。使用には注意が必要です。
  3. 仮想 NUMA は、大規模な仮想マシン (デフォルトでは仮想 CPU が 8 個を超える場合) の最適なパフォーマンスを確保するうえで重要な機能です。

vSphere の仮想 NUMA 機能の詳細については、次の記事を参照してください。

http://www.vmware.com/files/pdf/techpaper/VMware-vSphere-CPU-Sched-Perf.pdf(このホワイトペーパーは、現時点 (2015 年 6 月) では、vSphere 6 の追加事項を反映して更新されていません)

http://blogs.vmware.com/vsphere/tag/vnuma

 

 

まとめ

 

これで、「モジュール 6: メモリ パフォーマンス機能: メモリのホット アドを使用した仮想 NUMA」 は終了です。実習ラボをご利用いただきありがとうございました。 最後にアンケートへのご記入をお願いします。

時間が残っている場合は、この実習ラボに含まれているほかのモジュールが、それぞれの予定所要時間とともに表示されます。 マニュアル内のモジュールにすばやく移動するには、[More Options] - [Table of Contents] の順にクリックします。

 

モジュール 7: ストレージ パフォーマンスとトラブルシューティング (30 分)

ストレージ パフォーマンスのトラブルシューティングの概要


vSphere が導入された環境で発生するパフォーマンスの問題の約 90 % は、たいてい何らかの形でストレージと関係しています。 この数年でストレージ テクノロジーは著しく進歩し、ストレージのパフォーマンス向上に貢献してきました。次に示すような、注意事項がいくつかあります。

正しく設計された環境では、ストレージ ファブリック テクノロジー間にパフォーマンスの違いはありません。 正しく設計された NFS、iSCSI または FC の実装は、ほかの実装と同じように機能します。

相互接続技術の進歩にもかかわらず、パフォーマンスの限界はいまだにメディアの限界によるもので、実際、グローバル サポート サービス (GSS: VMware のサポート) が確認したストレージ パフォーマンス ケースのうち、構成に関連するものを除いたケースの 90 % がメディアに関連しています。 注意すべき点は次のとおりです。

特定のディスクから得られる IOPS の総数の目安は次のとおりです。

このため、特定の数のディスクを使用して達成できる IOPS の数を知りたい場合は、次の式で求められます。

このテストでは、パフォーマンスの低いストレージを突き止めるいくつかの方法と、VMware Storage DRS によるワークロード バランシングを導入してこの問題を解決する方法を実演します。最初に、デモ環境を準備します。


 

US キーボード以外をご使用のユーザーの方へ

 

US 配列以外のキーボードが接続されたデバイスをご使用の場合は、この実習ラボのモジュールを進める中で CLI コマンドやユーザー名、パスワードが入力しづらいと感じる場合があるかもしれません。

入力する必要のある CLI コマンド、ユーザー名、パスワードは、デスクトップにあるファイル README.txt からコピーしてペーストできます。

 

 

スクリーン キーボード

 

キーボードの入力に問題がある場合のもう 1 つの解決策として、スクリーン キーボードを使用する方法があります。 

それには、[Start] メニューから [On-Screen Keyboard] を選択するか、タスクバーのショートカットをクリックします。

 

 

元の状態への復帰

 

何らかの理由で操作を間違えた場合や実習ラボを中断した場合は、次の操作を実行して元の状態に戻し、現在のモジュールを最初からやり直してください。

タスクバーの [VMware vSphere PowerCLI] アイコンをクリックして PowerCLI シェル プロンプトを開きます。

 

 

モジュール再開のための仮想マシンのリセット

 

PowerCLI プロンプトで次のように入力します。

.\StopLabVMs.ps1

<Enter> キーを押します。

実行中のすべての仮想マシンが停止してその設定がリセットされ、モジュールを再開できるようになります。

 

 

このモジュールの開始

 

このモジュールを開始しましょう。

タスクバーのショートカットから Chrome を起動します。

 

 

vSphere へのログイン

 

vSphere にログインします。デフォルトのホーム ページは vSphere Web Client です。

何らかの理由でこの認証が機能しない場合は、このチェックボックスをオフにして次の認証情報を使用してください。

ユーザー名: CORP\Administrator
パスワード: VMware1!

 

 

UI の更新

 

この実習ラボでの手動入力を減らすために、多数のタスクがスクリプトで自動化されています。そのため、スクリプトの実行直後は、vSphere Web Client にインベントリの実際の状態が反映されていない可能性があります。

インベントリを手動で更新する必要がある場合は、vSphere Web Client の上部にある [更新] アイコンをクリックします。

 

 

[Hosts and Clusters] の選択

 

 

vSphere HTML5 Web Client


このモジュールでは、HTML5 バージョンの Web Client を利用することもできます。 このバージョンは即応性と安定性に優れており、同時にセキュリティも確保できるように設計されています。 

現在、Fling リリースでは使用できない機能があります。 最もよく使用するアクションや機能は次のとおりです。

各自の環境でこのクライアントを実行するには、https://labs.vmware.com/flings/vsphere-html5-web-clientを参照してください。

このモジュールで行う操作の大半は HTML5 バージョンでは機能しないため、ご注意ください。ここでは、Flash と HTML5 の両方のインスタンスを同時に開き、切り替えて使用することをおすすめします。

HTML5 Web Client は、[RegionA HTML5 Client] というラベルのブックマーク セクションにあります。


 

HTML5 Web Client のリンク

 

 

 

 

Fling とは

Fling の Web サイト (https://labs.vmware.com/about) から抜粋

VMware のエンジニアは、空き時間に長年温めてきた大量のプロジェクトに取り組んでおり、そのプロジェクト (「Fling」) に関するフィードバックを常に求めています。Fling と名付けられた理由は、Fling には短期間のシリアスではなく楽しい関係という意味があるためです。同様に、ここに用意されているツールは、ご自由に使用して検討していただくことができます。どのツールも、今後の製品サービスに組み込まれる保証はなく、サポートもされません。ただし、完全に無償でダウンロードし、お試しいただくことができます。

 

ストレージ I/O の競合



 

PowerCLI ウィンドウを開く

 

タスクバーの [VMware vSphere PowerCLI] アイコンをクリックしてコマンド プロンプトを開きます。

 

 

ストレージ ワークロードの開始

 

PowerCLI コンソールから次のように入力します。

.\StartStorageTest.ps1

<Enter> キーを押します。

仮想マシンが構成されて起動し、Iometer を使用してストレージ ワークロードが起動します。

このスクリプトの所要時間は約 5 分です。スクリプトの実行中の数分間、次の手順に目を通して、ストレージの遅延について把握しておいてください。

 

 

ディスク I/O の遅延

 

ストレージのパフォーマンスの問題について考えるとき、通常もっとも問題になるのは遅延であるため、ストレージ スタックを確認し、ストレージ スタックに含まれるレイヤーと、遅延が増大する可能性のあるレイヤーを把握する必要があります。

最上位のレイヤーは、ゲスト オペレーティング システムで稼働するアプリケーションです。 最終的に遅延がもっとも問題になる場所がここです。 これはアプリケーションに表れる遅延の合計量であり、ここにはゲスト OS、VMKernel 仮想化レイヤー、物理ハードウェアをはじめとする全ストレージ スタックの遅延が含まれます。 

アプリケーションは ESXi 仮想化レイヤーより上のレイヤーであるため、ESXi でアプリケーションの遅延を確認することはできません。

esxtop および vCenter Server でレポートされる 3 つの主な遅延は、ESXi から確認できます。 

最上部にあるのが GAVG (ゲストの平均遅延) であり、ESXi が検出できた遅延の合計量です。 

これはアプリケーションに表れる遅延の合計量ではありません。むしろ、GAVG (ESX で確認されている遅延の合計量) とアプリケーションに表れている実際の遅延とを比較すると、ゲスト OS がストレージ スタックに加えている遅延がどのくらいかわかり、ゲスト OS が正しく構成されているかどうか、またパフォーマンスの問題の原因になっていないかどうかを判断することもできます。 たとえば、ESX は GAVG が 10 ミリ秒であるとレポートしているのに、ゲスト OS アプリケーションまたは perfmon はストレージの遅延が 30 ミリ秒であるとレポートしている場合は、何らかの理由で 20 ミリ秒の遅延がゲスト OS レイヤーで発生していることを意味しているため、ゲスト OS のストレージ構成を重点的にデバッグする必要があります。

GAVG は 2 つの主要なコンポーネント (KAVG と DAVG) で構成されています。DAVG は基本的に、ドライバから HBA、ストレージ アレイまでのデバイスで費やされた時間であり、KAVG は ESXi のカーネルで費やされた時間です (つまり、超過した分はカーネルにより追加された時間です)。 

実際、KAVG は導出されるメトリックであり、ESXi では特に KAVG を計算していません。ESXi では次の式を使用して KAVG を求めます。

合計遅延  DAVG = KAVG

VMKernel での IO 処理はとても効率的に行われるため、IO がカーネルで待機すべき時間 (KAVG) はそれほど多くはないはずです。ですから、適切に構成または実行されている環境では、KAVG は 0 になるはずです。KAVG が 0 でない場合は、VMKernel 内のカーネル キューに IO がたまっていることを意味している可能性が高いと言えます。そのため、KAVG のほとんどの時間は QAVG (キューの平均遅延。下のキューのスロットが空き、下のスタックに移動できるようになるのを IO が待機してキューにたまっている時間) と等しくなります。

 

 

Iometer によりレポートされたストレージ パフォーマンスの表示

 

ストレージ スクリプトが完了すると、2 つの Iometer ウィンドウが表示されます。2 つのストレージ ワークロードが実行されています。

ストレージ ワークロードは perf-worker-02a と perf-worker-03a の両方で起動されます。ワークロードが安定し、2 台の仮想マシンのパフォーマンス測定値がほぼ同じになるまでに数分かかります。ディスクをテストしているこれらの仮想マシンは同じデータストアを共有しており、そのデータストアは飽和状態です。

パフォーマンスは Iometer の GUI で確認できます。

遅延時間 (平均 I/O 応答時間) は約 6 ミリ秒です。 

IOPS (1 秒あたりの合計 I/O 数) は低く、約 160 IOPS です。

スループット (1 秒あたりの合計 MB) は低く、約 2.7 MBPS です。

免責事項: この実習ラボは完全に仮想化された環境で実行されており、ESXi ホスト サーバも仮想マシンで実行されているため、物理ディスク スピンドルを個々のデータストアに割り当てることはできません。そのため、これらのスクリーンショットのパフォーマンス測定値は、実習ラボが実行されているクラウド環境の実際の負荷によって異なります。

 

 

perf-worker-03a の選択

 

  1. perf-worker-03a を選択します。

 

 

vCenter Server のストレージ パフォーマンス メトリックの表示

 

  1. [監視] を選択します。
  2. [パフォーマンス] を選択します。
  3. [詳細] を選択します。
  4. [チャート オプション] をクリックします。

 

 

パフォーマンス メトリックの選択

 

  1. [仮想ディスク] を選択します。
  2. [scsi0:1] のみを選択します。
  3. [このチャートのカウンタを選択:] で [なし] をクリックします。
  4. [書き込み待ち時間] と [書き込み速度] を選択します。
  5. [OK] をクリックします。

Iometer がワークロードを生成するために使用するディスクは scsi0:1 (ゲスト内の sdb) です。

 

 

vCenter Server のストレージ パフォーマンス メトリックの表示

 

perf-worker-02a でパフォーマンス チャートの構成を繰り返して、パフォーマンスが perf-worker-03a とほぼ同じであることを確認します。

ガイダンス: デバイスの遅延が 20 ミリ秒を超えると、アプリケーションのパフォーマンスに影響する場合があります。

このテスト用にプライベート データストアを作成した方法が原因で、遅延の値は実際にはかなり低くなっています。scsi0:1 は、perf-worker-03a と同じ ESXi ホスト上で実行されている perf-worker-04a の RAM ディスクに基づく iSCSI データストア (DatastoreA) に配置されています。そのため、完全に仮想化された環境の遅延はかなり低くなります。

vSphere には、ストレージ パフォーマンスの管理や制御に役立つストレージ機能がいくつかあります。

Storage DRS を構成してこの競合の問題を解決しましょう。

 

ストレージ クラスタと Storage DRS


データストア クラスタとは、リソースおよび管理インターフェイスを共有するデータストアの集合です。データストア クラスタとデータストアの関係は、クラスタとホストの関係のようなものです。データストア クラスタを作成する場合、vSphere Storage DRS を使用してストレージ リソースを管理することができます。

データストアをデータストア クラスタに追加すると、データストアのリソースはデータストア クラスタのリソースの一部になります。ホストのクラスタと同様に、データストア クラスタを使用してストレージ リソースを統合することで、データストア クラスタ レベルでリソース割り当てポリシーを適用できます。データストア クラスタごとに、次のリソース管理機能も使用できます。

容量使用率のロード バランシング: 容量使用率についてしきい値を設定できます。データストアの容量使用率がしきい値を超えると、Storage DRS は推奨を生成するか、Storage vMotion による移行を実行して、データストア クラスタ内で容量の使用を分散します。

I/O 遅延のロード バランシング: I/O 遅延のしきい値を設定して、ボトルネックを回避できます。データストアの I/O 遅延がしきい値を超えると、Storage DRS は推奨を生成するか、Storage vMotion による移行を実行して、I/O の高い負荷を軽減します。必ずストレージ ベンダーに問い合わせて、I/O 遅延のロード バランシングの使用に関する推奨事項を確認してください。

非アフィニティ ルール: 仮想マシン ディスクの非アフィニティ ルールを作成できます。たとえば、特定の仮想マシンの仮想ディスクを別個のデータストアに維持できます。デフォルトでは、仮想マシンのすべての仮想ディスクを同じデータストアに格納します。


 

データストア ビューへの切り替え

 

  1. データストア ビューに切り替えます。
  2. [vcsa-01a.corp.local] と [RegionA01] を展開します。

 

 

データストア クラスタの作成

 

  1. [RegionA01] を右クリックします。
  2. [ストレージ] を選択します。
  3. [新規データストア クラスタ...] をクリックします。

 

 

データストア クラスタの作成 (パート 1 / 6)

 

この実習ラボでは、ほとんどの設定をデフォルトのまま使用します。

  1. 新しいデータストア クラスタの名前として 「DatastoreCluster」 と入力します。
  2. [次へ] をクリックします。

 

 

データストア クラスタの作成 (パート 2 / 6)

 

  1. [次へ] をクリックします。

 

 

データストア クラスタの作成 (パート 3 / 6)

 

  1. [領域しきい値] しきい値を [50] に変更します。
  2. [次へ] をクリックします。

HOL はネストされた仮想環境であるため、信頼性の高い方法で大きい遅延のデモを行うのは困難です。そのため、I/O 遅延を使用したロード バランシングのデモは行いません。デフォルトではストレージ クラスタの不均衡が 8 時間ごとにチェックされますが、最小で 60 分に変更できます。

 

 

データストア クラスタの作成 (パート 4 / 6)

 

  1. [クラスタ] を選択します。
  2. [RegionA01-COMP01] を選択します。
  3. [次へ] をクリックします。

 

 

データストア クラスタの作成 (パート 5 / 6)

 

  1. [DatastoreA] と [DatastoreB] を選択します。
  2. [次へ] をクリックします。

 

 

データストア クラスタの作成 (パート 6 / 6)

 

  1. [終了] をクリックします。

 

 

Storage DRS の実行

 

Storage DRS で移行する仮想マシンの名前をメモします。

  1. [DatastoreCluster] を選択します。
  2. [監視] タブを選択します。
  3. [Storage DRS] を選択します。
  4. [今すぐストレージ DRS を実行] をクリックします。
  5. [推奨の適用] をクリックします。

ワークロードの 1 つを DatastoreA から DatastoreB に移動することが推奨されているのを確認します。 Storage DRS の推奨は容量に基づいています。 パフォーマンス データを収集してから 8 時間以上経過しないと、SDRS はパフォーマンスに基づくストレージの移動を実行しません。 ワークロードは開始したばかりであるため、さらに多くのデータが収集されるまで、SDRS はパフォーマンスに基づくワークロード調整のための推奨を行いません。

 

 

vSphere 6.0 の Storage DRS

 

  1. [管理] を選択します。
  2. [設定] を選択します。
  3. [Storage DRS] を選択します。
  4. Storage DRS 用に構成できるさまざまな設定を確認します。

vSphere 6.0 の Storage DRS では、以前の Storage DRS にあったいくつかの制限を排除するために、さまざまな機能強化が行われています。

Storage DRS ではデデュープ データストアの相互運用性が向上しており、データストアが同じデデュープ プールに組み込まれているかどうかを Storage DRS で特定できるようになったため、仮想マシンが別のデデュープ プールを使用しているデータストアに移行されなくなりました。

Storage DRS ではシン プロビジョニング データストアの相互運用性が向上しており、シン プロビジョニング データストアが同じストレージ プールに組み込まれているかどうかを Storage DRS で特定できるようになったため、仮想マシンが同じストレージ プールを使用しているデータストア間で移行されなくなりました。

Storage DRS ではアレイ ベースの自動階層化の相互運用性が向上しており、自動階層化を使用するデータストアを Storage DRS で特定し、自動階層化のタイプと頻度に応じて異なる処理を実行できるようになりました。

これらすべての機能強化に共通しているのは、そのすべてに VASA 2.0 が必要であるということです。そのため、ストレージ ベンダーが更新したストレージ プロバイダを用意している必要があります。

 

 

移行された仮想マシンの選択

 

  1. [ホストおよびクラスタ] ビューに戻ります。
  2. Storage DRS を使用して移行した仮想マシン (この場合は perf-worker-03a) を選択します。

 

 

スループットの向上と遅延の低減

 

  1. [監視] タブを選択します。
  2. [パフォーマンス] を選択します。
  3. [詳細] を選択します。

このモジュールで作成したパフォーマンス チャートが表示されます。

両方の仮想マシンで同じデータストアを共有していたときよりもスループットが向上し、遅延が低減していることを確認します (緑色の矢印)。

 

 

Iometer の GUI に戻ってパフォーマンスを確認

 

Iometer ワーカーに戻り、ここでもパフォーマンスの向上と遅延の低減がレポートされていることを確認します。

Iometer にこれらの高い数値が表示されるまで、しばらく時間がかかります (10 分程度)。これは、この実習ラボでのストレージ パフォーマンスの調整方法が原因です。ショートカットするには、停止して 30 秒待ってから 2 つのワーカーを再起動します。図の矢印を参照してください。その後、ワークロードが急増し、数分のうちに高いパフォーマンス レベルで安定します。

 

 

Iometer ワークロードの停止

 

ワークロードを停止します。

  1. Iometer GUI の [Stop Sign] ボタンをクリックします。
  2. [X] をクリックして GUI を閉じます。
  3. Iometer GUI の [Stop Sign] ボタンをクリックします。
  4. [X] をクリックして GUI を閉じます。

 

まとめとクリーンアップ



 

クリーンアップの手順

この実習ラボの残りの部分を実行できるようにリソースを解放するために、使用した仮想マシンをシャットダウンして構成をリセットする必要があります。

 

 

PowerCLI の起動

 

PowerCLI ウィンドウをまだ開いていない場合は、タスクバーの [VMware vSphere PowerCLI] アイコンをクリックしてコマンド プロンプトを開きます。

 

 

仮想マシンのパワーオフとリセット

 

PowerCLI コンソールで次のように入力します。

.\StopLabVMs.ps1

<Enter> キーを押します。

実行中のすべての仮想マシンが停止してその設定がリセットされます。

 

 

PowerCLI ウィンドウを閉じる

 

PowerCLI ウィンドウを閉じます。

これで別のモジュールに進むことができます。

 

 

要点

この実習ラボでは、容量とパフォーマンスに関してストレージのサイズを正しく設定することの重要性を確認しました。また、同じスピンドルを共有する 2 つのストレージ集中型連続ワークロードがある場合は、パフォーマンスに大きく影響する可能性があることも確認しました。できる限りワークロードは分離するようにしてください。順次ワークロードとランダム ワークロードは分離 (異なるスピンドル / LUN を使用) してください。

一般的に、ストレージの遅延は 20 ミリ秒未満に抑え、可能であればさらに低減することを目標として、遅延が頻繁に 60 ミリ秒以上に急増していないかを監視します。このように急増する場合は、詳しく調査すべきパフォーマンスの問題か何かがあると考えられます。

ガイダンス: vSphere の観点から、ほとんどのアプリケーションの場合、1 つの大規模なデータストアを使用しても、多数の小規模なデータストアを使用しても、パフォーマンスに影響しない場合がほとんどです。ただし、大規模な LUN を 1 つ使用する場合と複数の LUN を使用する場合との差はストレージ アレイによって異なり、ほとんどのストレージ アレイは複数 LUN 構成のほうが 1 つの大規模 LUN 構成より高いパフォーマンスを示します。

ガイダンス: 使用しているストレージ ベンダーのベスト プラクティスとサイズ設定ガイドラインに従って、各自の仮想環境に合わせてストレージのサイズ設定と調整を適切に行ってください。

 

 

まとめ

 

これで、「モジュール 7: ストレージ パフォーマンスとトラブルシューティング」 は終了です。実習ラボをご利用いただきありがとうございました。 最後にアンケートへのご記入をお願いします。

時間が残っている場合は、この実習ラボに含まれているほかのモジュールが、それぞれの予定所要時間とともに表示されます。 マニュアル内のモジュールにすばやく移動するには、[More Options] - [Table of Contents] の順にクリックします。

 

モジュール 8: ネットワーク パフォーマンス、基本概念、トラブルシューティング (15 分)

ネットワーク パフォーマンスの概要


Wikipediaで定義されているように、ネットワーク パフォーマンスとは、顧客が認識する通信製品のサービス品質を評価する指標を指します。

次のメトリックは重要と見なされています。

このモジュールでは、ネットワーク関連の問題の監視とトラブルシューティングを行う方法について説明し、各自の環境で発生する可能性がある同様の問題をトラブルシューティングできるようにします。


 

US キーボード以外をご使用のユーザーの方へ

 

US 配列以外のキーボードが接続されたデバイスをご使用の場合は、この実習ラボのモジュールを進める中で CLI コマンドやユーザー名、パスワードが入力しづらいと感じる場合があるかもしれません。

入力する必要のある CLI コマンド、ユーザー名、パスワードは、デスクトップにあるファイル README.txt からコピーしてペーストできます。

 

 

スクリーン キーボード

 

キーボードの入力に問題がある場合のもう 1 つの解決策として、スクリーン キーボードを使用する方法があります。 

それには、[Start] メニューから [On-Screen Keyboard] を選択するか、タスクバーのショートカットをクリックします。

 

 

元の状態への復帰

 

何らかの理由で操作を間違えた場合や実習ラボを中断した場合は、次の操作を実行して元の状態に戻し、現在のモジュールを最初からやり直してください。

タスクバーの [VMware vSphere PowerCLI] アイコンをクリックして PowerCLI シェル プロンプトを開きます。

 

 

モジュール再開のための仮想マシンのリセット

 

PowerCLI プロンプトで次のように入力します。

.\StopLabVMs.ps1

<Enter> キーを押します。

実行中のすべての仮想マシンが停止してその設定がリセットされ、モジュールを再開できるようになります。

 

 

このモジュールの開始

 

このモジュールを開始しましょう。

タスクバーのショートカットから Chrome を起動します。

 

 

vSphere へのログイン

 

vSphere にログインします。デフォルトのホーム ページは vSphere Web Client です。

何らかの理由でこの認証が機能しない場合は、このチェックボックスをオフにして次の認証情報を使用してください。

ユーザー名: CORP\Administrator
パスワード: VMware1!

 

 

UI の更新

 

この実習ラボでの手動入力を減らすために、多数のタスクがスクリプトで自動化されています。そのため、スクリプトの実行直後は、vSphere Web Client にインベントリの実際の状態が反映されていない可能性があります。

インベントリを手動で更新する必要がある場合は、vSphere Web Client の上部にある [更新] アイコンをクリックします。

 

 

[Hosts and Clusters] の選択

 

 

ネットワークの競合のデモ


ネットワークの競合とは、複数の仮想マシンが同じリソースをめぐって争っている状況を指します。

VMware ハンズオン ラボでは、実際の環境をシミュレートする方法ですべてのネットワーク リソースを使用することはできません。

そのため、このモジュールではネットワーク負荷の生成に焦点を合わせて、各自の環境でネットワークの問題が発生している可能性がある場合に確認するポイントについて説明します。

実習ラボの実行時の環境の負荷が原因で、画面に表示される結果が異なる場合があります。


 

PowerCLI の起動

 

PowerCLI ウィンドウをまだ開いていない場合は、タスクバーの [VMware vSphere PowerCLI] アイコンをクリックしてコマンド プロンプトを開きます。

 

 

ネットワーク負荷の開始

 

PowerCLI ウィンドウで次のように入力して実習ラボ用の仮想マシンを起動し、ネットワーク負荷の生成を開始します。

.\StartNetTest.ps1

<Enter> キーを押します。

 

 

仮想マシンの選択

 

  1. ESXi ホスト esx-02a.corp.local 上の perf-worker-06a を選択します。
  2. [監視] タブを選択します。
  3. [パフォーマンス] タブを選択します。
  4. [少子亜] を選択します。
  5. [チャートオプション] をクリックします。

 

 

チャート オプションの選択

 

  1. [ネットワーク] を選択します。
  2. [なし] をクリックします。
  3. [perf-worker-06a] を選択します。
  4. [ドロップされた受信パケット数] と [ドロップされた転送パケット数] を選択します。
  5. [OK] をクリックします。

注: ここに示されているメトリックのうち選択できないものがある場合は、スクリプトによって仮想マシンが起動されるまで待ってから、[チャート オプション] をもう一度選択して開いてください。

 

 

チャートの監視

 

これまでにかかった時間によっては、ネットワーク負荷が完了している場合もあります。その場合も、実行されていた負荷をチャートで確認することができます。この図では、説明をわかりやすくするために、ネットワークを 2 回実行しています。

  1. ここでは、perf-worker-06a 上のネットワーク負荷のグラフを確認できます。
  2. ここでは、仮想マシンの負荷を監視し、データ送信の実際の数値を確認することができます。

確認するポイントに関するアドバイスを次に示します。

[例]:

この数値が予想よりも低い場合は、ネットワークまたは仮想マシンに問題が発生している可能性があります。

[ドロップされた受信パケット数] と [ドロップされた転送パケット数]:

これは競合が生じているかどうかを示しています。つまり、パッケージがドロップされているため再送信が必要になる場合があります。これはネットワークの競合または問題が原因で発生する可能性があります。

ホストのページに移動して、これが仮想マシンの問題であるかホストの問題であるかを確認します。

 

 

ホストの選択

 

  1. [esx-01a.corp.local] を選択します。
  2. [監視] タブを選択します。
  3. [パフォーマンス] タブを選択します。
  4. [詳細] を選択します。
  5. ドロップダウン メニューから [ネットワーク] を選択します。
  6. [チャート オプション] をクリックします。

 

 

チャート オプションの選択

 

  1. [なし] をクリックします。
  2. [esx-01a.corp.local] を選択します。
  3. [ドロップされた受信パケット数] と [ドロップされた転送パケット数] を選択します。
  4. [OK] をクリックします。

 

 

チャートの監視

 

  1. ホストでドロップされたパケットがあるかどうかを確認します。

この例では、ホストでドロップされたパケットはないため、仮想マシンの問題であることがわかります。

ハンズオン ラボの性質上、実習ラボでは結果が異なる場合があります。

 

まとめとクリーンアップ



 

クリーンアップの手順

この実習ラボの残りの部分を実行できるようにリソースを解放するために、使用した仮想マシンをシャットダウンして構成をリセットする必要があります。

 

 

PowerCLI の起動

 

PowerCLI ウィンドウをまだ開いていない場合は、タスクバーの [VMware vSphere PowerCLI] アイコンをクリックしてコマンド プロンプトを開きます。

 

 

仮想マシンのパワーオフとリセット

 

PowerCLI コンソールで次のように入力します。

.\StopLabVMs.ps1

<Enter> キーを押します。

実行中のすべての仮想マシンが停止してその設定がリセットされます。この後、別のモジュールに進むことができます。

 

 

PowerCLI ウィンドウを閉じる

 

PowerCLI ウィンドウを閉じます。

これで別のモジュールに進むことができます。

 

 

要点

この実習ラボでは、vCenter に組み込まれている VMware の監視ツールを使用して、仮想マシンとホストのネットワークの問題を診断する方法について説明しました。

パフォーマンスのトラブルシューティングを行う方法はほかにも多数あります。

パフォーマンスのトラブルシューティングの詳細については、以降のモジュールに進むか、次の記事を参照してください。

Troubleshooting network performance issues in a vSphere environment

http://kb.vmware.com/kb/1004087 

 

 

まとめ

 

これで、「モジュール 8: ネットワーク パフォーマンス、基本概念、トラブルシューティング」 は終了です。実習ラボをご利用いただきありがとうございました。 最後にアンケートへのご記入をお願いします。

時間が残っている場合は、この実習ラボに含まれているほかのモジュールが、それぞれの予定所要時間とともに表示されます。 マニュアル内のモジュールにすばやく移動するには、[More Options] - [Table of Contents] の順にクリックします。

 

モジュール 9: ネットワーク パフォーマンス機能: 予約機能を備えた Network I/O Control (45 分)

Network I/O Control の概要


vSphere 6.0 では、VMware vSphere の Network I/O Control (NIOC) 機能が強化され、帯域幅予約などのいくつかの優れた新機能がサポートされるようになりました。

機能の一覧を示します。

これらの機能は、vSphere 5 で使用できる次のような既存の NetIOC 機能に加えて導入されています。


 

アーキテクチャ

 

NIOC のアーキテクチャの概要

 

Network I/O Control のデモ


ハンズオン ラボの性質上、Network I/O Control のライブ デモを行うことはできません。そのため、手順を追って機能を確認できるオフライン デモをご用意しました。

Network I/O Control のインタラクティブ デモを表示するには、こちらをクリックしてください。新しいブラウザ タブまたは新しいブラウザ ウィンドウでデモが表示されます。 オフライン デモが終了したら、ブラウザの右上隅にある [Return to the Lab] リンクをクリックしてください。

実習ラボはそのままバックグラウンドで実行されるので注意してください。 オフライン デモの終了までに時間がかかりすぎると、実習ラボがスタンバイ モードに移行することがあります。その場合は、モジュールの完了後に実習ラボを再開する必要があります。


まとめとクリーンアップ



 

クリーンアップの手順

これはインタラクティブ デモであるため、このモジュールではクリーンアップは必要ありません。

インタラクティブ デモの間に実習ラボが一時停止された場合は、実習ラボを再開してください。

 

 

要点

この実習ラボでは、NIOC を使用して特定のタイプの仮想マシンとワークロード用に帯域幅を予約できることについて説明しました。

NIOC の詳細については、次の記事を参照してください。

Performance Evaluation of Network I/O Control in VMware vSphere6

http://www.vmware.com/files/pdf/techpaper/Network-IOC-vSphere6-Performance-Evaluation.pdf

vSphere Network I/O Control バージョン 3について説明する YouTube のビデオ (英語)

https://www.youtube.com/watch?v=IvczUp6d8ZY

 

 

 

 

まとめ

 

これで、「モジュール 9: ネットワーク パフォーマンス機能: 予約機能を備えた Network I/O Control」 は終了です。実習ラボをご利用いただきありがとうございました。 最後にアンケートへのご記入をお願いします。

時間が残っている場合は、この実習ラボに含まれているほかのモジュールが、それぞれの予定所要時間とともに表示されます。 マニュアル内のモジュールにすばやく移動するには、[More Options] - [Table of Contents] の順にクリックします。

 

モジュール 10: パフォーマンス監視ツール: esxtop CLI の概要 (30 分)

esxtop の概要


vSphere 環境のパフォーマンス監視と診断にはいくつかのツールが使用できます。最適なのは esxtop を使用して、別のツールや方法で判別したパフォーマンスの問題を診断して詳しく調査する方法です。esxtop は長期間のパフォーマンス監視用のツールではありませんが、一定の期間の特定の問題や仮想マシンを詳しく調査または監視するのに便利なツールです。

この実習ラボでは、30 分間で esxtop を使用して CPU、メモリ、ストレージ、ネットワークのパフォーマンスのトラブルシューティングを説明します。このモジュールでは、esxtop のさまざまなビューと、ビューごとに異なる負荷を紹介しています。 これは esxtop の詳細な説明を意図したものではなく、このツールに慣れ親しんで各自の環境で使用できるようになることを目的としています。

esxtop の各メトリックの詳細とその意味については、このモジュールの最後に示すリンクを参照することをおすすめします。

次のモジュールでは、ESXtopNGC プラグインについて説明します。このプラグインは、vSphere Web Client の GUI 機能を利用して、より強力かつ新しい方法でホスト レベルの統計情報を表示します。

vSphere 環境全体の日常的なパフォーマンス監視には、vRealize Operations Manager (vROPs) を使用できます。これは仮想インフラストラクチャ全体の監視に使用できる強力なツールです。このツールには、概要を示すダッシュボード ビューが搭載され、データを分析して問題発生の危険を特定するインテリジェンス機能が組み込まれています。 この実習ラボのモジュール 12 では、vROPs の基本的な機能について説明します。また、この実習ラボが終了したら、vROPs に関するその他の実習ラボを確認して、日常的な監視についての理解を深めることをおすすめします。


 

US キーボード以外をご使用のユーザーの方へ

 

US 配列以外のキーボードが接続されたデバイスをご使用の場合は、この実習ラボのモジュールを進める中で CLI コマンドやユーザー名、パスワードが入力しづらいと感じる場合があるかもしれません。

入力する必要のある CLI コマンド、ユーザー名、パスワードは、デスクトップにあるファイル README.txt からコピーしてペーストできます。

 

 

スクリーン キーボード

 

キーボードの入力に問題がある場合のもう 1 つの解決策として、スクリーン キーボードを使用する方法があります。 

それには、[Start] メニューから [On-Screen Keyboard] を選択するか、タスクバーのショートカットをクリックします。

 

 

元の状態への復帰

 

何らかの理由で操作を間違えた場合や実習ラボを中断した場合は、次の操作を実行して元の状態に戻し、現在のモジュールを最初からやり直してください。

タスクバーの [VMware vSphere PowerCLI] アイコンをクリックして PowerCLI シェル プロンプトを開きます。

 

 

モジュール再開のための仮想マシンのリセット

 

PowerCLI プロンプトで次のように入力します。

.\StopLabVMs.ps1

<Enter> キーを押します。

実行中のすべての仮想マシンが停止してその設定がリセットされ、モジュールを再開できるようになります。

 

 

このモジュールの開始

 

このモジュールを開始しましょう。

タスクバーのショートカットから Chrome を起動します。

 

 

vSphere へのログイン

 

vSphere にログインします。デフォルトのホーム ページは vSphere Web Client です。

何らかの理由でこの認証が機能しない場合は、このチェックボックスをオフにして次の認証情報を使用してください。

ユーザー名: CORP\Administrator
パスワード: VMware1!

 

 

UI の更新

 

この実習ラボでの手動入力を減らすために、多数のタスクがスクリプトで自動化されています。そのため、スクリプトの実行直後は、vSphere Web Client にインベントリの実際の状態が反映されていない可能性があります。

インベントリを手動で更新する必要がある場合は、vSphere Web Client の上部にある [更新] アイコンをクリックします。

 

 

[Hosts and Clusters] の選択

 

 

vSphere HTML5 Web Client


このモジュールでは、HTML5 バージョンの Web Client を利用することもできます。 このバージョンは即応性と安定性に優れており、同時にセキュリティも確保できるように設計されています。 

現在、Fling リリースでは使用できない機能があります。 最もよく使用するアクションや機能は次のとおりです。

各自の環境でこのクライアントを実行するには、https://labs.vmware.com/flings/vsphere-html5-web-clientを参照してください。

このモジュールで行う操作の大半は HTML5 バージョンでは機能しないため、ご注意ください。ここでは、Flash と HTML5 の両方のインスタンスを同時に開き、切り替えて使用することをおすすめします。

HTML5 Web Client は、[RegionA HTML5 Client] というラベルのブックマーク セクションにあります。


 

HTML5 Web Client のリンク

 

 

 

 

Fling とは

Fling の Web サイト (https://labs.vmware.com/about) から抜粋

VMware のエンジニアは、空き時間に長年温めてきた大量のプロジェクトに取り組んでおり、そのプロジェクト (「Fling」) に関するフィードバックを常に求めています。Fling と名付けられた理由は、Fling には短期間のシリアスではなく楽しい関係という意味があるためです。同様に、ここに用意されているツールは、ご自由に使用して検討していただくことができます。どのツールも、今後の製品サービスに組み込まれる保証はなく、サポートもされません。ただし、完全に無償でダウンロードし、お試しいただくことができます。

 

esxtop の CPU 機能のデモ


esxtop を使用することで、ホストと仮想マシンの両方のレベルでパフォーマンスのほぼあらゆる側面の問題を診断することができます。このセクションでは、esxtop を対話式モードで使用して CPU パフォーマンスを表示する方法を扱います。


 

PowerCLI ウィンドウを開く

 

タスクバーの [VMware vSphere PowerCLI] アイコンをクリックしてコマンド プロンプトを開きます。

 

 

仮想マシンの CPU 負荷の開始

 

次のように入力します。

.\StartCPUTest2.ps1

<Enter> キーを押します。 実習ラボ用の仮想マシンが起動します。

 

 

PuTTY の起動

 

 

 

esx-01a への SSH 接続

 

  1. ホスト esx-01a.corp.local を選択します。
  2. [Open] をクリックします。

 

 

esxtop の起動

 

  1. ESXi シェルで次のように入力します。
esxtop

<Enter> キーを押します。

2.     [Maximize] アイコンをクリックして、情報を最大限に表示できるようにします。

 

 

CPU ビューの選択

 

esxtop を起動すると、デフォルトで CPU ビューが表示されます。

念のため、「c」 を入力して CPU ビューに切り替えます。

 

 

表示されるフィールドのフィルタリング

 

次のように入力します。

f

使用可能なフィールド (カウンタ) のリストが表示されます。

表示スペースがあまりないため、[ID] カウンタと [Group Id] カウンタを削除します。

これを行うには、次の文字を入力します (注: 大文字と小文字が区別されるため、必ず大文字で入力してください)。

A
B

<Enter> キーを押します。

 

 

仮想マシンのみフィルタリング

 

この画面には、仮想マシンと ESXi ホストの両方のプロセスのパフォーマンス カウンタが表示されます。

仮想マシンの値のみを表示するには、

(大文字で) 次のように入力します。

V

 

 

仮想マシンの負荷の監視

 

2 台のワーカー仮想マシン perf-worker-01a および perf-worker-01b の負荷を監視します。

どちらもゲスト CPU の使用率が 100 % (またはほぼ 100 %) であるはずです。そうでない場合は、CPU ワークロードが開始されるまで待ちます。

監視対象の重要なメトリックの 1 つに、%RDY (CPU 待機率) があります。 このメトリックは、「ワールド」 が実行可能な状態にありながら、承認のために CPU スケジューラを待機している時間の割合を示します。 このメトリックは 1 つの仮想 CPU につき 100 % まで上昇する可能性があります。つまり、2 つの仮想 CPU を搭載している場合、その最大値は 200 % です。 目安としては、この値が 1 つの仮想 CPU につき 5 % 未満になるようにします。ただし、これは常にアプリケーションに左右されます。

ワーカー仮想マシンが 1 つの仮想 CPU につき 5 % のしきい値を超えていないかどうかを確認します。 esxtop がすぐに更新されるようにするには、スペース キーを押します。

 

 

perf-worker-01a の設定の編集

 

perf-worker-01a の構成方法を見てみましょう。

  1. perf-worker-01a 仮想マシンをクリックします。
  2. [アクション] をクリックします。
  3. [設定の編集...] をクリックします。

 

 

perf-worker-01a への仮想 CPU の追加

 

  1. 仮想 CPU 数として [2] を選択します。
  2. [OK] をクリックします。

 

 

perf-worker-01b の設定の編集

 

パフォーマンス向上のために perf-worker-01b に仮想 CPU を追加しましょう。

  1. perf-worker-01b 仮想マシンをクリックします。
  2. [アクション] をクリックします。
  3. [設定の編集...] をクリックします。

 

 

perf-worker-01b への仮想 CPU の追加

 

  1. 仮想 CPU 数として [2] を選択します。
  2. [OK] をクリックします。

 

 

%USED と %RDY の監視

 

PuTTY (esxtop) ウィンドウに戻ります。

各仮想マシンに仮想 CPU を追加したので、このスクリーンショットのような結果になるはずです。

 

 

%USED と %RDY の監視 (続き)

 

数分後、CPU ベンチマークで追加の仮想 CPU が使用され始め、%RDY がさらに増えます。これは、システムで CPU の競合と SMP スケジューリング (%CSTP 増加の原因) が発生しているためです。ESXi ホストでは 2 台のアクティブな仮想マシンに 4 つの仮想 CPU が搭載されており、各仮想マシンが 2 つの仮想 CPU をそれぞれ 100 % で実行しようとし、リソースをめぐって争っています。また、ESXi ホストの実行にも CPU リソースが必要になるため、これも CPU の競合の原因となります。

 

esxtop のメモリ機能のデモ


esxtop を使用することで、ホストと仮想マシンの両方でパフォーマンスのほぼあらゆる側面の問題を診断することができます。このセクションでは、esxtop を対話式モードで使用してメモリ パフォーマンスを表示する方法を扱います。


 

仮想マシンの負荷の開始

 

PowerCLI ウィンドウで次のように入力します。

.\StartMemoryTest.ps1

<Enter> キーを押して、メモリ負荷を開始します。

スクリプトを実行している間に次の手順に進むこともできますが、どのウィンドウも閉じないでください。閉じるとメモリ負荷が停止します。

 

 

メモリ ビューの選択

 

PuTTY ウィンドウで次のように入力します。

m

メモリ ビューが表示されます。

 

 

適切なフィールドの選択

 

次のように入力します。

f

使用可能なカウンタのリストが表示されます。

表示スペースがあまりないため、2 つのカウンタ [ID] と [Group Id] を削除します。

これを行うには、(大文字で) 次のように入力します。

B
H
J

 <Enter> キーを押して esxtop 画面に戻ります。

 

 

仮想マシンのみ表示

 

この画面には、仮想マシンと ESXi ホストの両方のプロセスのパフォーマンス カウンタが表示されます。

仮想マシンの値のみを表示するには、

(大文字で) 次のように入力します。

V

 

 

競合未発生時のメモリ負荷の監視

 

ワーカー仮想マシンの負荷が開始されると、esxtop ウィンドウの上部で確認できるようになります。

確認が推奨されるメトリックを次に示します。

MCTL:

バルーン ドライバがインストールされているかを示します。 インストールされていない場合は、まずインストールすることをおすすめします。

MCTLSZ:

バルーンがどの程度拡張されているかを示します。 つまり、オペレーティング システムから回収されているメモリの容量です。これは 0 である必要があります。

SWCUR:

仮想マシンがどの程度スワップしているかを示します。これは 0 である必要がありますが、残りのカウンタが適切であればこのカウンタも問題ありません。

SWR/S:

スワップ ファイルの読み取り量を示します。

SWW/S:

スワップ ファイルの書き込み量を示します。

実習ラボによっては、すべてのカウンタが適切である場合があります。ただし、ネストされた実習ラボの性質上、どのような値が表示されるかは不明です。そのため、すべて問題ないかどうかを確認してください。

 

 

perf-worker-04a のパワーオン

 

  1. perf-worker-04a を右クリックします。
  2. [Power] を選択します。
  3. [Power On] をクリックします。

 

 

競合発生時のメモリ負荷の監視

 

ESXi ホスト上でメモリ競合が発生したことがわかります。

perf-worker-04a には VMware Tools (およびバルーン ドライバ) がインストールされていないため、バルーニング ターゲットがありません。

perf-worker-02a および 03a ではそれぞれ約 400 MB のバルーニングが実行されています。

perf-worker-02a、03a、04a はディスクにスワップしています。

 

 

ワーカーの負荷の停止

 

  1. 2 つの VM Stats Collector ウィンドウを閉じて、負荷スクリプトの開始後に発生したワーカーの負荷を停止します。

 

esxtop のストレージ機能のデモ


esxtop を使用することで、ホストと仮想マシンの両方でパフォーマンスのほぼあらゆる側面の問題を診断することができます。このセクションでは、esxtop を対話式モードで使用してストレージ パフォーマンスを表示する方法を扱います。


 

実習ラボの開始

 

PowerCLI ウィンドウで次のように入力します。

.\StartStorageTest.ps1

<Enter> キーを押して実習ラボを開始します。

実習ラボの準備完了までに約 5 分かかります。スクリプトが完了するまでの間に、ほかの手順に進んでもかまいません。

スクリプトの開始後に表示されたウィンドウは閉じないでください。

 

 

さまざまなビュー

 

esxtop でストレージを確認する際には、複数のオプションから選択できます。

esxtop では、3 種類の画面でストレージ統計情報を確認できます。

次のオプションもあります。

このモジュールでは、仮想マシン画面に焦点を合わせます。

PuTTY ウィンドウで (小文字で) 次のように入力します。

v

仮想マシン ストレージ ビューが表示されます。

 

 

適切なフィールドの選択

 

次のように入力します。

f

使用可能なカウンタのリストが表示されます。

ここでは、すべてのカウンタが vscsi id 別に追加されます。

すべてのカウンタを表示できる十分なスペースがあるため、(大文字で) 次のように入力してこれも追加します。

A

完了したら <Enter> キーを押します。

 

 

仮想マシンの負荷の開始

 

この実習ラボの最初に実行した StartStorageTest.ps1 スクリプトが完了すると、デスクトップにこのような IOmeter ウィンドウが 2 つ表示されます。

表示されない場合は、次のスクリプトをもう一度実行します。

.\StartStorageTest.ps1 

完了するまで待ちます。

 

 

仮想マシンの負荷の監視

 

この実習ラボでは 4 台の仮想マシンが実行されています。

そのうち 2 台は IOmeter ワークロードを実行しており、ほかの 2 台は RAM ディスクを使用する iSCSI ストレージ ターゲットです。ストレージ ターゲットとして RAM ディスクを使用しているため、ディスク I/O は生成しません。

ここで確認するメトリックを次に示します。

CMDS/S:

これは 1 秒あたりのコマンドの合計量で、1 秒あたりの I/O 処理数 (IOPS) と、監視対象のデバイスまたは仮想マシン間で送受信される SCSI 予約、ロック、ベンダー文字列要求、Unit Attention コマンドなど、 その他の SCSI コマンドが含まれます。

多数のメタデータ操作 (SCSI 予約など) がない限り、ほとんどの場合は CMDS/s = IOPS です。

LAT/rd と LAT/wr:

仮想マシンで認識される平均応答時間、つまり読み取りと書き込みの I/O を示します。

ここでは、現在 Iometer の負荷を実行しているワーカー仮想マシン (perf-worker-02a および 03a) の CMD/s の値が高くなっており、大量の I/O が生成されていることがわかります。

また、書き込みのみを実行しているため、LAT/wr の値が高くなっています。

ハンズオン ラボの性質上、画面に表示される数値は異なる場合があります。

 

 

デバイスまたはカーネルの遅延

 

次のように入力します。

d

デバイス ビューに移動します。

ストレージ ワークロードがデバイス vmhba33 (ソフトウェア iSCSI アダプタ) 上にあることがわかります。DAVG (デバイスの遅延) および KAVG (カーネルの遅延)を確認します。DAVG は 25 ミリ秒未満である必要があり、KAVG (カーネルが原因で発生する遅延) は常に 2 ミリ秒未満という非常に低い値に抑える必要があります。

この例では、遅延は許容範囲内に収まっています。

 

 

ワーカーの負荷の停止

 

両方の Iometer ワーカーを閉じます。

  1. 完了したら、[STOP] をクリックして IOmeter ワークロードを停止します。
  2. 右上隅にあるバツ印をクリックしてウィンドウを閉じます。

 

esxtop のネットワーク機能のデモ


esxtop を使用することで、ホストと仮想マシンの両方でパフォーマンスのほぼあらゆる側面の問題を診断することができます。このセクションでは、esxtop を対話式モードで使用してネットワーク パフォーマンスを表示する方法を扱います。


 

実習ラボ用の仮想マシンの起動

 

PowerCLI ウィンドウで次のように入力します。

 .\StartNetTest.ps1

<Enter> キーを押します。

スクリプトの実行には数分かかるため、その間に次の手順に進んでください。

 

 

ネットワーク ビューの選択

 

PuTTY ウィンドウで次のように入力します。

n

ネットワーク ビューが表示されます。

 

 

適切なフィールドの選択

 

次のように入力します。

f

使用可能なカウンタのリストが表示されます。

表示スペースがあまりないため、2 つのカウンタ [PORT-ID] と [DNAME] を削除します。

これを行うには、(大文字で) 次のように入力します。

A
F

完了したら <Enter> キーを押します。

 

 

負荷の監視

 

メトリックを監視します。

ハンズオン ラボの実行環境の負荷が原因で、画面に表示される結果が異なる場合があります。

画面は自動的に更新されますが、以下を押すことで強制的に更新することもできます。

スペース キー

確認するメトリックを次に示します。

%DRPTX と %DRPRX:

ドロップされた送信パッケージと受信パッケージの割合。

この数値が増加している場合は、ネットワーク使用率が高くなっている可能性があります。

最初の手順で実行した StartNetTest.ps1 スクリプトによって仮想マシンが起動され、その 2 分後にネットワーク負荷が 5 分間実行されます。

この手順までに 7 分以上かかった場合は、負荷を確認できない可能性があります。

 

 

ネットワーク負荷の再開

 

ネットワーク負荷をさらに 5 分間実行する場合は、PowerCLI ウィンドウに戻ります。

PowerCLI ウィンドウで次のように入力します。

 .\StartupNetLoad.bat

<Enter> キーを押します。

ネットワーク負荷がさらに 5 分間実行されます。 その間に esxtop をさらに調べることができます。

 

 

ネットワーク負荷の完了

 

すでに説明したように、負荷は自動的に停止します。そのため、PowerShell ウィンドウに 「Network load complete」 と表示されると、負荷は生成されなくなります。

 

まとめとクリーンアップ



 

クリーンアップの手順

この実習ラボの残りの部分を実行できるようにリソースを解放するために、使用した仮想マシンをシャットダウンして構成をリセットする必要があります。

 

 

PowerCLI の起動

 

PowerCLI ウィンドウをまだ開いていない場合は、タスクバーの [VMware vSphere PowerCLI] アイコンをクリックしてコマンド プロンプトを開きます。

 

 

仮想マシンのパワーオフとリセット

 

PowerCLI コンソールで次のように入力します。

.\StopLabVMs.ps1

<Enter> キーを押します。

実行中のすべての仮想マシンが停止してその設定がリセットされます。この後、別のモジュールに進むことができます。

 

 

要点

この実習ラボでは、esxtop を使用して CPU、メモリ、ストレージ、ネットワークの負荷を監視する方法について説明しました。

ここでご紹介したのは、esxtop で実行できる機能のごく一部です。

esxtop の詳細については、次の記事を参照してください。

Yellow-Bricks の esxtop に関するページ (英語)

http://www.yellow-bricks.com/esxtop/

esxtop に関する必読書 (英語)

https://communities.vmware.com/docs/DOC-9279

 

 

まとめ

 

これで、「モジュール 10: パフォーマンス ツール: esxtop CLI の概要」 は終了です。実習ラボをご利用いただきありがとうございました。 最後にアンケートへのご記入をお願いします。

時間が残っている場合は、この実習ラボに含まれているほかのモジュールが、それぞれの予定所要時間とともに表示されます。 マニュアル内のモジュールにすばやく移動するには、[More Options] - [Table of Contents] の順にクリックします。

 

Conclusion

Thank you for participating in the VMware Hands-on Labs. Be sure to visit http://hol.vmware.com/ to continue your lab experience online.

Lab SKU: HOL-1704-SDC-1-JA

Version: 20161206-130131