Home > Blogs > Japan Cloud Infrastructure Blog > タグ別アーカイブ: パフォーマンス

タグ別アーカイブ: パフォーマンス

vSphere 5.5 の新機能紹介 – VMのパフォーマンスを最大化する、待ち時間感度 (Latency-Sensitivity) 機能

今回ご紹介する機能は、「待ち時間感度(Latency-Sensitivity)」 – CPU オーバーヘッドをできるだけ小さくすることにより仮想マシンのパフォーマンスを最大化し、同時にアプリ応答時間および遅延を最小化する機能です。

vSphere 環境上での仮想マシンのパフォーマンスについては、バイナリートランスレーション技術の最適化および VT-x やAMD-V といった CPU ベンダーによるハードウェア仮想化支援機能を利用することにより、これまでも物理ホスト上でネイティブに動作する場合とほとんど遜色のないパフォーマンスをたたき出すことに成功しています。
First SAP SD Benchmark on vSphere 5 Shows Performance within 6% of Native” (英語)
http://blogs.vmware.com/performance/2011/08/first-sap-sd-benchmark-on-vsphere-5-shows-performance-within-6-of-native.html
Performance Study of Oracle RAC on VMware vSphere® 5.0” (英語)
http://www.vmware.com/resources/techresources/10295

 CPU 処理のオーバーヘッドおよびネットワーク遅延

とはいえ従来の ESXi には、ある仮想マシンにたいし(特定の)物理 CPU(コア)を排他的に使用できるようにする機能はなく、他の仮想マシンと物理 CPU が共有されてしまうことを完全に排除することはできませんでした。(代替え策として、CPU アフィニティと予約を組み合わせることにより、特定の物理 CPU をある仮想マシンに「擬似的に」占有させるしか方法がありませんでした)
したがって、仮想マシンにたいして必ず物理 CPU が割り当てられていることを保証する手段がなかったため、マイクロ秒単位の非常に短時間のレスポンスを要求するようなアプリケーション(アプリ全体の中ではごく一部ですが)を、仮想マシン上で要求レベルどおりに動作させることは、大きなチャレンジでした。

また ESXi では、複数の仮想マシンにたいし効率よく物理 CPU を割り当てるために、 CPU スケジューリング機能を備えています。CPU スケジューリング機能は、VMware による長年の進化改良により、非常に効率のよいものになっていますが、ハイパーバイザが介在するため、VM-VM間、VM-ハイパーバイザ間のコンテキスト・スイッチングなど、ごく微少なオーバーヘッドが生じてしまいます。

また ESXi では、仮想マシン上の仮想 NIC と物理ホスト上の物理 NIC 間に、仮想スイッチを介在させるなどの、ネットワーク仮想化技術を実装しています。仮想ネットワークでパケットの頻繁な転送処理による効率低下を防止するため、仮想マシン-VMkernel間のパケット転送は、バッチによって処理しています(これを仮想 NIC コアレッシングといいます)。
これとは別に、仮想マシン側で短いパケットの多数受信した場合 CPU コストがかかります。受信処理を効率化し、仮想マシンの CPU コストを低下させるために、VMXNET3 仮想 NICでは、LRO (Large Receive Offload)という機能を実装しています。LRO 機能により、複数の短いパケットを単一の長いパケットにアグリゲートします。これにより、パケット処理における CPU コストを削減し、CPU 使用率を低下させています。
これらの仮想ネットワークのパケット転送効率化機能により、パケット受信および CPU 処理の効率化を図っていますが、その一方、(短い)パケットを受信したばあい、アグリゲート処理が加わるため若干の遅延が生じてしまいます。

待ち時間感度(Latency-Sensitivity)機能

上記の CPU スケジューリングのオーバーヘッドおよびネットワーク遅延を最小化するため、新たに「待ち時間感度」を設定する機能が導入されました。
待ち時間感度を設定することにより、下記のような効果を実現します。

  1. 物理リソースへの排他的アクセス権を与える
    CPU スケジューラは、CPU オーバーヘッドの有無を含むいくつかの要因を考慮し、物理 CPU への排他的アクセスを有効化するかどうか決定します。さらに、仮想 CPU の予約値を100%に設定することにより、仮想マシンの物理 CPU への排他アクセスを保証することが可能になります。
    (注意:待ち時間感度を有効化するには、仮想マシンのメモリ予約を設定しておく必要があります)
  2. 仮想化レイヤーをバイパスする
    仮想 CPU を100%予約することにより、一旦物理 CPU への排他アクセスが得られると、その物理 CPU 上は他のコンテキストが存在しないため、VMkernelの CPU スケジュールレイヤーをバイパスし、仮想マシンから直接 VM exit処理が可能になります。(VM exit についてはこちらを参照下さい)
    これにより、VMkernel とのコンテキスト・スイッチングに要する CP Uコストが削減されます。VM exit 処理そのものはなくなりませんが、EPT などのハードウェア仮想化支援機能を利用している場合は、VM exit 処理のコストは相対的に小さいものになります。
  3. 仮想化レイヤーのチューニングを行う
    仮想 NIC として、VMXNET3 準仮想化デバイスを使用している場合は、仮想 NIC コアレッシングと LRO を自動的に無効化します。
    これにより、パケット送受信にともなう遅延を最小化します。
    SR-IOV などの物理 NIC のパススルー技術を同時に使用した場合に、さらにパフォーマンスを向上させることが可能になります。

待ち時間感度(Latency-Sensitivity)設定を有効化する方法

待ち時間感度機能は、ESXi ホスト単位ではなく、仮想マシンごとに個別に設定します(デフォルトでは無効化されています)。
Web Client にて仮想マシンアイコンを右クリックし、[設定の編集]を選択します。[仮想マシン オプション]タブを選択し、[設定]を展開すると、「待ち時間感度」という欄が表示されます(vSphere Clientではこの機能は設定できません)。

上図のように、メニューには、”低”, “標準”, “中”, “高”の4つの項目がありますが、このうち”低”と”中”は試験的サポートとなりますので説明は省略します。
他の(正式サポートされる)メニュー項目の意味は下記の通りです。

  • – 上記で説明した機能すべてが有効化されます。[高]に設定するには、仮想マシンのメモリ予約が必要です。
  • 標準 – 「待ち時間感度」機能が無効化され、通常の仮想マシンの設定になります。

「待ち時間感度」機能利用時の注意点

「待ち時間感度」機能を有効化し、ある仮想マシンが物理 CPU を占有した場合、(たとえその仮想マシンがアイドル状態であっても)他の仮想マシンはその物理 CPU を利用できない場合がありますので、結果としてホスト全体の CPU 使用率が低下してしまう可能性があります。
また、仮想 NIC コアレッシングと LRO が無効化されるため、パケット送受信に関する遅延は低下しますが、パケットあたりの CPU コストが上昇します。したがってネットワークの全体的なスループットが低下し、CPU 使用率が上昇する可能性があります。
このような注意点がありますので、「待ち時間感度」機能をむやみに有効化することは避け、CPU のレスポンスタイムやネットワーク遅延に厳しいアプリケーションを動作させる場合のみ、有効化することをお奨めします。
「待ち時間感度」機能の技術詳細、ベンチマーク結果などについてホワイトペーパーが公開されておりますので、そちらも参照下さい。
Deploying Extremely Latency-Sensitive Applications in VMware vSphere 5.5
https://www.vmware.com/resources/techresources/10383

VMware vSphere 5.X vMotion パフォーマンス

VMware のライブマイグレーション機能であるvMotion は、初期のvSphere から使用可能な機能となり、バージョンアップを重ねる度に継続して機能拡張がなされています。vSphere 5.0 では、vMotion パフォーマンスの改善が行われており、最新のvSphere 5.1 では、共有ストレージを必要としない拡張vMotion が可能となりました。パフォーマンスの部分は、単純な機能比較では分かりにくい、目立たないところではありますが、運用上影響のあるところになります。

クラスタ内で負荷を均等化し、仮想化環境の統合率を高めるDRS(Distributed Resource Scheduler)といったvSphere の機能も、vMotion のテクノロジーがベースとなっています。お客様がDRS の導入をためらう理由として、稼働中の仮想マシンをライブマイグレーションすることによる、サービスに与える影響への懸念があります。今回ご紹介する試験の結果から、vSphere 4.1 を使用した多くのケースでサービスの中断なしに移行可能なこと、さらに非常に高負荷な環境であってもvSphere 5.0 の機能拡張によりスムーズに移行可能なことが確認できます。

以下のTechnical Paper では、vMotion のアーキテクチャと具体的な改善点、vSphere 4.1 とvSphere 5.0 を比較したvMotion のパフォーマンス試験、vMotion のベストプラクティスが提供されています。このテクニカルホワイトペーパーの内容について、一部要約する形でご紹介していきます。

VMware vSphere® vMotion® Architecture, Performance and Best Practices in VMware vSphere® 5

 

アーキテクチャ

仮想マシンのライブマイグレーションは、ハイスピードネットワークリンク越しに仮想マシンの状態を、移行元ホストから移行先ホストへ移行します。vMotion の実行状態には次の3つのコンポーネントがあります。

1. 仮想デバイスの状態(CPU、ネットワーク、ディスクアダプタ、SVGA等)
2. ネットワークとSCSI 装置の接続
3. 仮想マシンの物理メモリ

1. 仮想デバイスの状態
vMotion は、vSphere の仮想マシンの仮想デバイスの状態を8MB 以下のサイズにシリアル化する機能を活用します。ケースによっては128MB を超えることもあり、ハイスピードネットワーク越しに素早く移動することができます。

2. ネットワークとSCSI 装置の接続
vNIC は物理アダプターと独立した独自のMAC アドレスを持っているため、仮想マシンはホスト間を移動することができ、同一のサブネットにおいて移行後にもネットワークコネクションを維持することが可能です。移行先のvSphere ホストは、RARP(Reverse ARP)パケットを物理ネットワークに送信し、スイッチのMAC アドレステーブルを更新します。移行は、クライアントから完全に透過的に行われます。また、SAN やNAS といった共有ストレージは、ディスク状態の移行を容易にします。

3. 仮想マシンの物理メモリ
仮想マシンの物理メモリは、移行するコンポーネントの中で大きな要素となり、メモリ移行の効率性は、vMotion のパフォーマンスにおいて、最も重要な部分となります。仮想マシンのメモリ状態は3つのフェーズを経由します。

Phase 1: ゲストトレースフェーズ
このフェーズから移行が開始されます。トレースは移行中にゲストによって実施される変更をトラックするため、ゲストのメモリページで実行されます。メモリトレースは短時間ながら顕著なワークロードスループットの低下を引き起こす可能性があります。このインパクトは、ゲストメモリサイズに比例します。
Phase 2: プリコピーフェーズ
仮想マシンのメモリは、反復したプロセスで移行元から移行先ホストにコピーされます。プロセスの最初にメモリ全部をコピーし、続くプロセスでは、前回のコピーから修正された部分のみをコピーします。コピーされるメモリページの数は、移行中のゲストOSにより、vSphereホスト上で変更されるメモリに依存します。
Phase 3: スイッチオーバフェーズ
最後のフェーズにおいて、移行元vSphere ホストは瞬間的に静止し、最後のメモリ変更が移行先にコピーされ、仮想マシンは移行先のvSphere ホストで再開します。ゲストはこのステップ中に短時間停止します。 このフェーズ間隔は一般的に1秒未満ですが、ゲストのパフォーマンスインパクト(一時的な遅延の増加)が一番大きなフェーズとなります。影響はネットワーク、共有ストレージ、ホストハードウェア、vSphere のバージョン、ゲストのワークロードといった複数の要素に依存します。

 

vSphere 5.0 の機能拡張

1. 複数のネットワークアダプタの使用
vSphere 5.0 では、vMotion に複数のネットワークアダプタを使用する、マルチネットワークアダプタ機能が追加されています。後のセクションでご紹介するテストの結果から分かるように、移行時間を大幅に削減することが可能です。1台の仮想マシンのvMotion の際も、VMkernel はvMotion トラフィックを全ての有効なネットワークアダプタにロードバランスします。

2. Metro vMotion
vSphere 5.0 は、遅延に対応したメトロvMotion 機能を提供します。vMotion ネットワークの遅延の制限を10msec に増加させます。遅延に関しては下記KBも合わせてご参照ください。
High latency vMotion networks (2008096)

3. SDPS (Stun During Page Send)
vSphere 5.0 では、プリコピーフェーズにおけるメモリコピーの収束問題によりvMotion が失敗することがなくなりました。vSphere 4.1 以前のバージョンでは、仮想マシンが、vMotion によるプリコピーより早いペースでメモリを修正してしまうような高負荷環境で、vMotion が失敗するケースがありました。vSphere 5.0 の機能拡張では、仮想マシンをスローダウンし、メモリ修正レートをプリコピーの転送レートより遅くして、結果としてvMotion の失敗を防ぎます。

4. その他改善
・メモリトレースのインパクト改善
・vMotion 後に通常のパフォーマンスに戻るまでの時間の改善
・10GbE 帯域を効果的に使用する改善

 

パフォーマンス評価

vMotion のパフォーマンスを計測するにあたり、ウェブサーバ、メールサーバ、データベースサーバを含む、重要なTier1 アプリケーションの大きなドメインと、大規模デスクトップ仮想マシンの移行を必要とするVDI シナリオを考慮しています。下記それぞれケースについて、解説をしていきます。

1. ウェブ環境におけるvMotion パフォーマンス
2. メール環境におけるvMotion パフォーマンス
3. データベース環境におけるvMotion パフォーマンス
4. VDI/Cloud 環境におけるvMotion パフォーマンス



図1. テスト環境の構成

図1にテスト環境の構成を示します。詳細な試験環境の構成については、テクニカルホワイトペーパーを参照ください。

 

1. ウェブ環境におけるvMotion パフォーマンス

このセクションでは、ウェブアプリケーションサーバのパフォーマンスへの、vMotion  の影響について検証しています。試験では、vMotion 中にサービス品質要件を満たしているユーザセッションの数に焦点を当てており、SLA を保証するクラウド環境へのWeb アプリケーション実装を検討しているお客様の手助けになるものです。

試験には、SPEC(Standard Performance Evaluation Corporation)によって規定される、業界標準のWeb サーバワークロードであるSPECweb2005 を使用します。詳細な試験環境の構成については、テクニカルホワイトペーパーを参照ください。

試験では専用の10GbE ネットワークアダプタをvMotion トラフィックに使用しています。図2の試験結果は、vMotion 実行時間がvShpere 4.1 に比べて、vSphere 5.0 では37%の削減があり、vMotion のパフォーマンス改善があることを示しています。10GbE の帯域を効率的に最大限使用するvSphere 5.0 の機能拡張により最適化されています



図2. vMotion 移行時間 (vSphere 4.1, vSphere 5.0)

図3のグラフでは、vSphere 4.1 環境でQoS(TIME_GOOD)を満たすSPECweb2005 のユーザセッション数をプロットしています。vMotion 実行中に顕著な2カ所のパフォーマンスの影響が表れています。最初の凹みはゲストトレースフェーズで発生し、2番目の凹みはソースホスト上の仮想マシンが瞬間的に静止し、移行先ホスト上で再開するスイッチオーバフェーズで発生しています。この2つの凹みにも関わらず、ネットワークコネクションのドロップ、タイムアウトは発生せずにSPECweb2005 のベンチマークは継続して動作しました。



図3. vMotion 移行時のWeb サーバのパフォーマンス(vSphere 4.1)

図4のグラフでは、vSphere 5.0 環境でQoS(TIME_GOOD)を満たすSPECweb2005 のユーザセッション数をプロットしています。vSphere 5.0 の機能拡張で、メモリトレースの影響を最小化しているため、ゲストトレースフェーズの凹みは小さくなり、スイッチオーバフェーズでのみ顕著な凹みが確認できます。このような高負荷にもかかわらず、スイッチオーバフェーズでゲストが静止する時間は約1秒となり、移行後に通常レベルのパフォーマンスに戻るまでは5秒未満となります。



図4. vMotion 移行時のWeb サーバのパフォーマンス(vSphere 5.0)

vSphere 4.1 とvSphere 5.0  を比べたとき、vMotion 移行時間と移行中のゲストパフォーマンスに、大きな改善があることが確認できます。

次のWeb 環境における試験では、10GbE ネットワークと1GbE ネットワークを使用した際のパフォーマンスを、それぞれvSphere4.1 とvSphere 5.0 で比較しています。試験は、表1に記載された異なる負荷の3つの仮想マシン(アイドル状態、平均的な負荷、高負荷)でそれぞれで実施しています。



表1. テストシナリオ(vSphere 4.1, vSphere 5.0)

図5 の試験結果は、10GbE ネットワークをvMotion に使用した際のメリットを明確に表しています。vMotion 実行時間は、1GbE に比べ大幅に短くなっています。各テストシナリオについて、個別に説明を行います。



図5. 10GbE と1GbE ネットワークでのvMotion 移行時間(vSphere 4.1, vSphere 5.0)

アイドル状態の仮想マシン:仮想マシンがアイドル状態(CPU アクティビティなし)になっていますが、メモリは完全にtouch された状態(ゼロページではない)のシナリオです。
補足:vSphere はゼロページのデータ移行を最適化するため、このシナリオでは110秒かかっている1GbE を使用したケースでも、メモリがtouch された状態でないブート直後の仮想マシンの移行時間は9秒以下となります

平均的な負荷の仮想マシン:仮想マシンのCPU 使用率は、140%(esxtop %USED)となり、クライアントからのネットワークトラフィックは、2.5Gbps 程度ある状態です。10GbE ネットワークを使用したとき、vSphere 4.1, vSphere 5.0 両方で移行時間は大幅に短縮され、vSphere 5.0 の移行時間はvSphere 4.1 より若干短縮されています。

高負荷の仮想マシン:仮想マシンのCPU 使用率は、325%(esxtop %USED)で、クライアントからのネットワークトラフィックは、6Gbps 程度ある状態です。2つ目のシナリオと同様に、10GbE ネットワークを使用したとき、移行時間は大幅に短縮されています。
vSphere 4.1 で1GbE ネットワークのvMotion 移行中には、高い遅延が発生し、ネットワークコネクションのドロップがあったため、vSphere 4.1 のグラフをグレーで表示しています。VMkernel のログから、仮想マシンが1GbE ネットワークで転送するよりも早くメモリの修正を行うメモリアクセスパターンが確認できます。vSphere 5.0 では、SDPS(Stun During Page Send)がプリコピー失敗時に機能し、vMotion の進行をスムーズにするため、vMotion 中のコネクションドロップはありませんでした。

vSphere 5.0 のvMotion 機能強化により、高負荷の仮想マシンを実行したときや、ネットワーク帯域に制限があるときにも、クライアントのサービス影響は最小化されます。

 

2. メール環境におけるvMotion パフォーマンス

メールは組織において重要なコミュニケーションツールであり、IT部門はメールシステムをミッションクリティカルなアプリケーションと見なしています。このセクションの試験では、ワールドワイドのビジネス環境で広範囲に使用されているMicrosoft Exchage Server 2010 をvMotion の影響調査で使用します。

パフォーマンスの測定には、Exchange サーバの公式なパフォーマンス測定ツールである、MS Exchange Load Generator 2010(LoadGen)を使用します。詳細な試験環境の構成については、テクニカルホワイトペーパーを参照ください。

試験は、下記2つのシナリオで実施します。
シナリオ1: vMotion を1台のメールボックスサーバ(4000のヘビーユーザが使用)仮想マシンで実施する
シナリオ2: vMotion を2台のメールボックスサーバ(8000のヘビーユーザが使用)仮想マシンで実施する

図6は、Exchange サーバのvMotion にかかる時間をvSphere 4.1 とvSphere 5.0 で比較しています。移行元と移行先のホストは、1本の10GbE ポートで構成されています。



図6. vMotion 移行時間(vSphere 4.1, vSphere 5.0)

シナリオ1でvMotion の移行時間は、vSphere 4.1 では71秒となるのに対し、vSphere 5.0 では47秒となり、33%短くなっています。シナリオ2でも同様、vSphere 5.0 を使用した場合トータルの移行時間は34%短くなります。

表2は、シナリオ1においてvSphere 4.1 とvSphere 5.0 のアプリケーションに対する影響を比較したものです。



表2. vMotion 移行時のゲストへの影響(vSphere 4.1, vSphere 5.0)

この表は、vMotion 実行中にLoadGen で確認された、最大のキューレングスを示しています。キューレングスは、Exchage 環境のユーザエクスペリエンスとSLA を調査するための一般的なメトリックとして使用されるもので、キューの中のタスクの数は、Exchage サーバが迅速なタスクのディスパッチに失敗したときに増えていきます。vSphere 5.0 は219で、vSphere 4.1 の294より小さな値となっており、ユーザはvSphere 5.0 環境においてより良いレスポンスを得ることが確認できます。

移行中にTask Exception はカウントされていません。これは、vSphere 4.1 及びvSphere 5.0両方の環境において、vMotion 移行中にドロップしたExchenge サーバのタスクはないことを意味します。

このテスト結果は、大きなメモリを使用したEmail アプリケーション環境で、vMotion の影響が最小化されていることを示しています。

 

3. データベース環境におけるvMotion パフォーマンス

データベースのワークロードは、CPU、メモリ、ストレージといったリソースを極端に消費することから、vMotion パフォーマンス測定において重要な指標となります。このセクションでは、MS SQL サーバのOLTP パフォーマンスに対するvMotion の影響を調査しています。

ベンチマークツールとしては、オープンソースのDVD Store Version2 (DS2)を使用しています。DS2 は、顧客がログインし、製品をブラウズするといった、オンラインのeコマースDVDストアをシミュレートします。詳細な試験環境の構成については、テクニカルホワイトペーパーを参照ください。

試験は、下記2つのシナリオで実施します。
シナリオ1: 1台の仮想マシンによるシングルインスタンスSQL サーバ
シナリオ2: 2台の仮想マシンによるマルチインスタンスSQL サーバ

図7は、シナリオ1とシナリオ2での、vMotion の移行時間を表しています。この結果は、vSphere 5.0 を使用した際にトータルの移行時間を削減することを示します。また、シナリオ1(1台の仮想マシン)の移行時間において、2つのネットワークアダプタを使用したケースで移行時間が短縮されていることから、単一の仮想マシンがvMotion を実行する際でも、複数のネットワークアダプタが透過的にvMotion トラフィックをロードバランスすることが分かります。

vSphere 5.0 で追加された複数のネットワークアダプタをvMotion で使用する機能は、単一及び複数の仮想マシン移行において、トータルの移行時間をダイナミックに削減します。



図7. vMotion 移行時間(vSphere 4.1, vSphere 5.0)

図8は、vSphere 4.1 環境でベンチマーク中のSQL サーバの秒毎のオーダプロセスをプロットしており、2つの顕著な凹みが確認できます。最初の凹みは、ゲストトレースフェーズで発生し、2つ目の凹みはスイッチオーバフェーズで発生しています。スイッチオーバフェーズの間隔は1秒未満となり、通常のパフォーマンス再開までに必要な時間は、スイッチオーバステージの後9秒程度となります。かなりの負荷を処理している時であっても、全体的なパフォーマンス影響は深刻なものではありません。



図8. SQLサーバへの影響(vSphere 4.1)

図9は、vSphere 5.0 環境でベンチマーク中のSQL サーバの秒毎のオーダプロセスをプロットしており、1つの顕著な凹みが確認できます。vSphere 4.1 環境で確認されたゲストトレースフェーズの凹みは、vSphere5.0 でのメモリトレース影響の最小化により、小さなものになっています。アプリケーションのスループットが0になるスイッチオーバの間隔は0.5秒未満となり、通常のパフォーマンス再開までの時間は約7秒となります。



図9. SQL サーバへの影響(vSphere 5.0)

vSphere 5.0 は、vSphere 4.1 と比べたときに、vMotion 移行時間と、vMotion 中のゲストパフォーマンス影響に改善があります。これらのテスト結果は、vMotion のパフォーマンス影響は、大きなリソースを必要とするDB アプリケーション環境でも最小化されることを示しています。

 

4. VDI/Cloud 環境におけるvMotion パフォーマンス

VDI/Cloud 環境では、1台のホストに数百の小〜中サイズの仮想マシンが統合されるという点で、良く似た特徴を持っています。これらの環境の管理には、ダウンタイムのないメンテナンスや、トラブルシューティングといった観点で、vMotion を使用するメリットがあります。

VDI/Cloud 環境においてサービス影響時間を最小化するために、仮想マシンの移行時間はとても重要な指標になります。そのため、このセクションでの試験は、トータルの移行時間に焦点をあてています。試験は64台のデスクトップ仮想マシンを持つVMware View 環境で、ベンチマークツールとしてVMware View Planner2.0 を使用し実施しています。詳細な試験環境の構成については、テクニカルホワイトペーパーを参照ください。

図10は、移行テストの結果をサマライズしています。移行元と移行先ホストは、1つの10GbE ポートで構成されています。vSphere 5.0 では、移行元と移行先ホストでvMotion 用に2つの10GbE ポートを構成したケースもテストしました。



図10. VDI 環境での仮想マシン移行シナリオ(vSphere 4.1, vSphere 5.0)

この結果から、vSphere 4.1 と比べたときに、トータルの移行時間がvSphere 5.0 で大きく削減されていることが分かります(vSphere 4.1: 11分, vSphere 5.0: 2分)。

2つの10GbE アダプタを使用した際の改善は、このテストシナリオではわずかなものとなっています。これは、複数のエージェントが動作するvCenter サーバと、移行元、移行先のvSphere ホスト間のマネジメントレイヤの遅延が、帯域使用率を制限しているためです。この遅延のインパクトは、テストシナリオのように小さな仮想マシンだけで構成されたシナリオではより顕著になります。



図11. 移行シナリオにおけるネットワーク使用帯域(vSphere 4.1)

図11は、64台の仮想マシンの移行シナリオの間に、vMotion によって使用されるネットワーク帯域を示しています。vSphere 4.1 では、すでのホストあたり同時8台までの移行がサポートされており、結果として8個の分離したフェーズができています。それずれのフェーズで8台平行した仮想マシンの移行があり、ピーク時の帯域は8Gbps 近くになりますが、フェーズ間のネットワーク帯域の使用率は、vCenter 上で実行される複数のエージェント、移行元、移行先ホスト間のマネジメントレイヤの同期遅延によりidle としてマークされます。結果、仮想マシンあたりの平均移行時間は6秒であるのに、トータルの移行時間は11分になります。

 



図12. 移行シナリオにおけるネットワーク使用帯域(vSphere 5.0)

図12は、vSphere 5.0 でネットワーク帯域を効率的に活用する改善を示しています。vSphere5.1 と比べ、顕著なフェーズがなく、ピーク時のネットワーク使用率は、9Gbpsとなります。結果としてトータルの移行時間は2分に短縮されます。

 

vMotion ベストプラクティス

1. 10GbE ネットワーク
1GbE ネットワークの代わりに10GbE ネットワークを使用することで、vMotion のパフォーマンスは大きく改善されます。特に大きな仮想マシン(64GB以上)を使用する時は、複数の10GbE ネットワークアダプタを使用することで、さらにvMotion のパフォーマンスは改善されます。

2. CPU キャパシティ
ホストレベルでリソースプールを使用する際は、ホストのCPUキャパシティを全てコミットせず、少なくともvMotion のために30%の予約されないCPUを残します。vMotion を開始するとき、VMkernel は便宜的にCPUリソースを予約しようと試みますが、確保が失敗するとvMotion は進行しても、パフォーマンスに大きな影響があります。同様にリソースプールをDRS で使用するとき、クラスタレベルでは少なくとも10%のCPU キャパシティを予約しないことを計画します。クラスタ内の全てのCPU キャパシティを予約することは、ホスト間のDRS 移行に支障がでます。

3. スワップファイル
vSphere 5.0 及び以前のリリースでは、スワップファイルの保存領域にローカルのデータストアの指定が可能となりましたが、スワップファイルをローカルデータストアに保存することで、vMotion のパフォーマンスに影響がでることがあります。移行にかかる時間に懸念がある場合、仮想マシンのスワップファイルはSAN かNAS といった共有ストレージに保存してください。

4. 複数のネットワークアダプタの使用
vMotion 用に複数のネットワークアダプタを使用する場合、全てのvMotion vmnic を1つのvSwitch 配下に設定し、1つのvMotion vmknic をそれぞれのvmnic に作成してください。vmknic のプロパティで、それぞれのvmknic が異なるvmnic をアクティブで使用し、残りをスタンバイとして設定します。この方法では、もし1つのvmnic が切り離されたとき、vMotion は透過的にスタンバイのvmnic にフェイルオーバします。全てのvmnic が機能している時は、それぞれのvmknic はアサインされた専用のvmnic にトラフィックを転送します。

5. NIOC (Network I/O Control)
複数のトラフィックを同じネットワークアダプタでシェアする必要がある時は、NIOC を使用してください。NIOC については、下記テクニカルホワイトペーパーも合わせてご参照ください。
VMware® Network I/O Control: Architecture, Performance and Best Practices

6. NUMA
ESXi 5.0 では、ESXi ホストのNUMA 構成をゲストOS に公開します。この機能を使用する際は、仮想マシンを同じNUMA アーキテクチャを持ったホストで構成されたクラスタ間に適用してください。これは、最初にvNUMA を有効にされたマシンがパワーオンされた際に、仮想マシンが動作している物理ホストに対応したNUMA トポロジーがセットされるためです。異なるトポロジのホスト間をvMotion で移行した際には、その仮想マシンのvNUMA トポロジは物理NUMA トポロジに最適化されずに、潜在的にパフォーマンスの低下を引き起こします。

 

結論

VMware vSphere vMotion はvSphere の最も有名な機能の1つで、仮想データセンターの管理に大きな利益をもたらします。アプリケーションの可用性と応答性においてユーザが認知するインパクトなしに、リソースのロードバランスを可能にし、ダウンタイムを防ぎ、トラブルシュートに柔軟性を提供します。

vSphere 5.0 は、vMotion の機能拡張と新機能を紹介していて、その中には複数のネットワークアダプタの使用や、10GbE 帯域の有効活用や、Metro vMotion や、移行中のアプリケーションパフォーマンスへのインパクト削減があります。vSphere 4.1 環境と比較し、vSphere 5.0 の環境でのvMotion パフォーマンスを定量化するために、4つの環境(ウェブ、メール、データベース、VDI/Cloud)で試験を実施しています。結果として、vSphere 5.0 ではvSphere 4.1 に対し、vMotion 移行時間とアプリケーションのパフォーマンスへのインパクトの点で、大きな改善があることが確認できました。

 

ここまで、vSphere 5.0 でのvMotion のパフォーマンス改善について解説を行ってきました。最新のvSphere 5.1 では今回説明したvSphere 5.0 の機能拡張に加え、共有ストレージを必要としない拡張vMotion が可能になっています。次回は、vSphere 5.1 の拡張vMoiton ついてテクニカルホワイトペーパーを基にご紹介します。

 

大規模環境のためのvCenter Server 5.1データベースのパフォーマンス改善とベストプラクティス その3

大規模環境でのvCenterサーバデータベースベストプラクティス

ここでは、vSphere 5.1で強化ポイントを最大限利用するためのデータベース設計のベストプラクティスをご紹介します。この中には、Oracle Database(以下 Oracle)やSQL Serverのディスクのレイアウトや、様々なテーブルに存在する統計情報の整理の方法、パフォーマンス向上のためのテーブルやインデックスの分離方法、OracleやSQL Serverのパラメータのチューニング方法、例えばSQL Serverのcost threshold for parallelismに関する内容が含まれます。その他一般的なvCenter Serverのベストプラクティスは、Performance Best Practices Guide for VMware vSphere 5.1をご確認ください。

 Oracle、SQL Serverのディスクレイアウト
vCenter Serverはデータベースサーバに多くのDisk I/Oを発生させる可能性があります。これらのI/Oは複数のLUN及びディスクスピンドルに分散させることが推奨です。次に示すのがそのガイドラインです。

 Oracle
以下の7個に分散させることが推奨です。
・ /u01 – system01.dbf, undotbs01.dbf
・ /u02 – sysaux01, temp01.dbf
・ /u03 – vpxdata01.dbf
・ /u04 – vpxindx01.dbf
・ /oralog – redo01a.log, redo02a.log, redo03a.log
・ /oralog_mirror – redo01b.log, redo02b.log, redo03b.log
・ /oraarch – archive destination.

SQL Server
以下の4個に分散させることが推奨です。
・mssql01 – master and msdb databases(.mdf, .ldf)
・mssql02 – tempdb(.mdf, .ldf), also set the initial size to 10GB
・mssql03 – VCDB(.mdf, .ldf)
・mssql04 – VCDB Backup location
 

更新量の多いテーブルに対するインデックス統計情報の更新

SQL Server
SQL Serverにおけるコストベースオプティマイザーは、SQL文の効率的な実行計画を作成する際、テーブルとインデックスに関する統計情報を利用します。コストとは、処理に必要なCPU、メモリ、Disk I/O等のリソース消費量のことで、統計情報とはテーブルのレコード数などが該当します。SQL Serverでは、AUTO_UPDATE_STATISTICSオプションの定義に従い、統計情報のインデックスが自動的にアップデートされます。この設定はデフォルトで有効となっています。この統計情報の自動更新は、最後の自動更新以降に実行されたインサート、アップデート、デリートの数がしきい値に達した際に実行されます。このしきい値はテーブル内のレコード数に依存しますが、例えば、100万を超えるような大きなテーブルを持っている場合、自動更新は数千から場合によっては100万のインサート、アップデート、デリート処理の実施後ということになり、SQL Serverの動作に影響を与える可能性が出てきます。

vCenter Serverによって、vCenter Serverスキーマの中のいくつかのテーブルが非常に速いペースで更新され、これらのテーブル上のインデックス統計情報はどんどん古くなっていきます。これが原因で、データベースのパフォーマンスが落ちてしまいます。例えば、VPX_PROPERTY_BULLETIN、 VPX_ALARM、 VPX_EVENT、 VPX_EVENT_ARGは、vCenter Serverのデータベーススキーマの中で最も変化の激しいテーブルですが、先のテーブルサイズの問題により、これらの自動更新が適切なタイミングで実行されない可能性があります。この問題に対処するため、これらの更新の激しいテーブル上のインデックス統計情報を以下の方法で手動更新することも可能です。

データベースの統計情報更新:sp_updatestats VCDB;

テーブルの統計情報更新:UPDATE STATISTICS “table_name”;

例えば、UPDATE STATISTICS VPX_PROPERTY_BULLETIN

となります。

Oracle
コストベースオプティマイザーはデータアクセスに対する最適な方法を提供しますが、先のSQL Server同様、最新の統計データであるかどうかに依存します。古い統計情報はデータベースのレスポンスに悪い影響を及ぼす可能性があります。Oracle Database 10g/11gのデフォルト設定では、データベースは自動的に統計情報を収集します。この統計情報の自動収集機能は、それほど頻繁な更新を行わない多くのデータベースオブジェクトにおいては十分機能しますが、統計情報の収集がメンテナンス時間に行われ、かつ非常に大きなテーブルが頻繁に更新される様な環境では適切には動作しない可能性があります。このようなテーブル上の統計情報はすぐに古くなってしまいます。

vCenter Serverの動作により、データベースの内容は短時間で書き換わります。このため、統計情報がデータベースオブジェクトの特性を正確に表す事の出来る間隔で統計情報の収集を行うことが推奨となります。

テーブル、インデックス、テーブル内の個別コラム上の統計情報を収集するために、OracleのDBMS_STATSパッケージを利用することが可能です。

テーブルやインデックス上の統計情報が更新される間、OracleはテーブルやインデックスにアクセスしているSQL状態も無効にしますが、次に同じようなSQL実行された場合には、利用可能となった新しい統計情報に基づき自動的に新しい実行プランを自動的に選択、実行します。Oracle Database 10g以降でテーブルやインデックス統計情報を更新するためには、OracelパッケージのDBMS_STATSを使います。スキーマレベルで統計情報を集めるためには、GATHER_SCHEMA_STATSプロシジャを使います。以下をご参照ください。

exec.dbms_stats.gather_schema_stats
(ownname = ‘VCDB’,
estimate_percent = 20,
method_opt = ‘for all columns size auto’,
options = ‘gather’,
cascade = true);

パフォーマンス向上のための、テーブルおよびインデックスの分割方法

SQL Server
サイズが大きく、高いトランザクションデータベースのために、非クラスタ化インデックス、tempdbを独自のファイルグループ内に移動する事も出来ます。これはVMwareとしてはテストを行っていませんが問題なく動作可能です。しかしながら、この方法は試験的な手法かつ、データベースファイルの変更を伴いますので、ご了承の上ご利用いただくのと同時に、実施前に必ずデータベースのバックアップを取得いただくようお願いいたします。

Oracle
上記した推奨のDisk配置に加え、/U03 (data file)からインデックスを分けることも可能です。

SQL Serverエンタープライズエディションの機能を利用する方法
SQL ServerはマルチCPU上のパフォーマンスを最大限利用するため、クエリの並列処理を行います。この方法では、マルチプロセッサで複数のスレッドを処理することにより、クエリとインデックスの処理を改善することが可能です。パラレル実行は、一つ以上のスレッドの利用が可能で、シリアル実行は一つのスレッドのみの実行が可能です。

SQL Serverでは、’max degree of parallelism’値で、並列処理の最大値を指定し、並列実行の数を制限することが出来ます。この値によりクエリの並列実行のためのスレッドリソースの指定を行います。

’cost threshold of parallelism’オプションは、クエリの並列プランが実行される際の閾値をしています。シーケンシャルにクエリを実行したときのコストがこの値よりも大きい場合にクエリの並列実行を実施します。

SQL Serverエンタープライズディションの機能
1.max degree of parallelism値の設定例
sp_configure ‘max degree of parallelism’, ((n-1)/2) -1;
※”n” はプロセス数

2. cost threshold of parallelism値の設定例
sp_configure ‘cost threshold for parallelism’, 15;
※推奨値は15ですが、これ以上の値(最大25まで)に設定することも可能です。

まとめ
3回に渡ってvCenter Serverのデータベースのベストプラクティスに関してご説明させていただきました。このような最適化を行うことにより、以下が可能となります。

・より大きな環境への対応
・データベース上のリソースのオーバーヘッドの削減
・効率的で高い能力を持った統計情報の収集、処理

御拝読、誠にありがとうございました!

関連記事はこちら(その1その2)をご覧ください。

大規模環境のためのvCenter Server 5.1 データベースのパフォーマンス改善とベストプラクティス その2

データベースパフォーマンスの改善

このセクションではその1 に引き続き、vCenter Server 5.1 の統計情報管理に関する主要な改善点を説明します。vCenter Server は、大量のデータを収集保持しており、データベースのパフォーマンスに大きな影響を受けます。

vSphere5.1 では、主要な2つの改善点があります。
・データベースのストアドプロシージャ改善による、ロールアップとTopN プロシージャ部分のリソースオーバヘッドの削減
・効率的なハイレベル統計情報のサポート

具体的には下記3つの最適化により、上記の改善を実現しています。
・ステージングテーブルの除去
・統計テーブルのパーティション
・ストアドプロシージャの再構成

 

ステージングテーブルの除去
vSphere4.1 とvSphere5.0 では、ステージングテーブルを用い、大規模環境でバースト的に生じる統計情報を収容していました。ステージングテーブルには3つの種類があります。1つ目のステージングテーブルは、5分間の統計としてvCenter Server に使用されるものです。一定間隔の後、このテーブルは2つ目のステージングテーブルに切り替わります。平行して、いっぱいになった2つ目のステージングテーブルは解析され、全ての5分間の統計情報は、過去1日間のテーブルに取り込まれます。3つ目のステージングテーブルは、ステージングテーブル間の移動をスムーズにするためのバッファーとして使用します。
しかしvSphere5.1 でサポートする大規模なインベントリー管理のためには、よりスケーラブルなソリューションが必要となります。vSphere5.1 ではこれらのステージングテーブルを除去し、代わりに統計テーブルをパーティションすることでこの問題を解決しています。この変更により、vCenter Sever は5分間の統計を、過去1日間のテーブルに直接取り込むことで、統計情報の収集プロセスを大幅に改善しました。ステージングテーブルの除去により、より堅牢に統計情報を保持することが可能となります。VMware ナレッジベース(KB2011523, KB1003878)でより多くの関連情報をご確認いただけます。

表2は、1時間あたりに取り込まれる統計情報を収集レベル毎に表した物です。例えば収集レベル4の場合、付記に記載のある1000台のホスト(32CPU, 2000Datastore, 4NIC)と、10000台の起動したVM(1vCPU, 1disk, 1NIC)環境で、1時間あたり8000万の統計情報が収集されます。環境によっては異なる数の統計情報が収集されるかもしれません。この表は、統計レベル毎のI/Oアクティビティ(KBps)も表しています。

表2. テスト環境でvCenter Server が収集し、データベースにプッシュするレベル毎の統計情報数

ステージングテーブルの除去は、統計情報の取り込みロジックを再設計することを可能にし、データベースのリソースオーバヘッドを削減し、1回にデータベースに保存できる統計情報の数を増やすことで、vCenter Server のスケーラビリティを拡張しました。

 

統計テーブルのパーティション
vCenter Server の統計テーブルには3つのI/O ソースが関係してきます。統計情報の取り込み、異なる統計情報間隔の間でのロールアップ、期限が切れた統計情報の削除です。これらのI/O は統計テーブルの競合を起こし、オペレーションに長時間でゆらぎのある遅延をもたらします。もともと日次、週次、月次、年次の統計情報毎に1つのテーブルがあり、このテーブルは非常に大きな規模のインベントリーになる可能性があります。vSphere5.1 は統計テーブルを再設計しパーティションすることで競合を削減し、パフォーマンスを改善します。

表3. 統計テーブルを小さなサブテーブルに分割し、それぞれが短い時間間隔の統計を保持します。例えば日次の統計情報テーブルはサブテーブルにパーティションされ、それぞれのサブテーブルは30分の統計情報のみ保持します。

vSphere5.1 はこれらの変更により
・テーブルへの取り込みが大幅に改善されました。
・ロールアップの性能が大きく改善されました。ロールアッププロセスは適切に調整され、ロールアップ手順のパフォーマンスは向上し、表4が示す通りの時間となりました。
・データ削除時のパフォーマンスが大幅に改善され、事実上ディスクへの全てのI/O が排除されました。期限の切れた統計情報の削除はデータの期限が切れた際の簡単な処理になり、削除時間を数秒にまで削減しました。
・高い統計レベルが以前に比べてより効率的にサポートされるようになりました。

表4. SQL サーバで異なるレベルの統計情報を収集した際のロールアップ平均時間

 

ストアドプロシージャの再構成
ここまで述べてきた変更に加えて、vSphere5.1 には過去のリリースに比べ効率化されたストアドプロシージャが含まれています。例えばデータセンターとクラスターのグラフでは、CPU 使用率Top10 の仮想マシンを表示することが可能です。このグラフは、 CPU 使用率、メモリーといった、TopN の仮想マシンを決めるため統計に数学的手法を使用するTopN クエリーから計算され、TopN の日次のテーブルに格納されます。これら日次のTopN 統計情報は、定期的に週次、月次、年次のテーブルにロールアップされます。これらTopN の手順は、より効率的に書き換えられています。かつては10分かかっていたかもしれない処理が、今では完了まで1分未満となります。これらの変更により、ページをロードするUI のパフォーマンスを改善し、データベースのI/O を削減します。

 

このセクションでは、vCenter Server データベースの具体的な改善内容を説明しました。引き続きその3 では、データベースパフォーマンスのためのベストプラクティスをご紹介していきます。

関連記事はこちら(その1 その3 )をご覧ください。

 

大規模環境のためのvCenter Server 5.1 データベースのパフォーマンス改善とベストプラクティス その1

vCenter Server バージョン5.1 では、より高いパフォーマンス、低いレイテンシを実現し、かつ統計情報を合理的に処理する改善が行われています。以下URL のTechnical Paper では、これらの改善点の解説と、vCenter Server デー タベースのパフォーマンスと大規模環境におけるベストプラクティスが提供されております。こちらのベストプラクティスの内容を3 回に渡り、ご紹介していきます。
http://www.vmware.com/resources/techresources/10302

エグゼクティブサマリ

VMware vCenter Server 5.1 では、統計サブシステムに対するいくつかの重要な改善が行われております。
統計データは、vCenter Server データベースのストレージに大きな影響を与えるため、vSphere のパフォーマンスが妨げられないようにデータを取り扱う必要があります。
vCenter Server 5.1 では、データベースのストアドプロシージャ、特にロールアップとTopN 手順に関する改善を通して、データベースのリソースオーバーヘッドを削減しています。

本ドキュメントでは、改善点と、改善点を利用するためのデータベースのベストプラクティスを提供します。
・Oracle Database とSQL Server のためのディスクを配置する方法
・非常に変わりやすいテーブルのインデックス統計を更新する方法
・パフォーマンス向上のためにテーブルとインデックスを切り離す方法
・SQL Server のEnterprise Edition の機能を利用する方法
・Oracle Database とSQL Server の特定のパラメータを調整する方法(例えばSQL Server のための同時実行閾値)

vCenter Server が管理することができるインベントリ(仮想マシン、ホスト、クラスタ、データストア、クラスタ)の最大値に近い環境でvCenter Server を導入を検討する場合、5.1 での改善は非常に重要です。

イントロダクション

vCenter Server では、リレーショナルデータベースに重要なデータが保持し続けられ、データベースはvCenter Server パフォーマンスの重要なコンポーネントとなります。
このデータは1) インベントリと構成データ、2) タスクとイベントデータ、3) アラームデータ、4) 統計データの4つのカテゴリに分類されております。

この中でも統計データがデータベースのかなりの部分を消費するため、適切な統計機能はデータベース全体のパフォーマンスの重要な考慮点となります。
統計情報の収集と処理は、vCenter Server パフォーマンスのための重要な構成要素となります。

図1.vCenter Server における統計サブシステムの概要
vCenter Server には、統計サブシステムのために保存期間と統計レベルの2 つのキーとなるセッティングがあります。
vCenter Server は定期的に各々のESXi ホストから統計情報を集めて、リレーショナルデータベースへデータが保持し続けられます。データベースは、いろいろな間隔でこのデータをまとめるためのいくつかのストアドプロシージャを順番に実行します。

各ESXi ホストは、20 秒ごとに統計情報を集め、vCenter Server では、これらはリアルタイム統計と呼ばれています。vSphere Client のパフォーマンスタブで詳細ボタンを選ぶことによって、リアルタイム統計を見ることができます。クライアントでは、直接ESXi ホストからリアルタイム統計を受け取っているため、データのタイムリーさを確実にして、データベースにストレスを与えません。

これらの20 秒の統計情報は定期的に5 分の統計情報にまとめられ、vCenter Server はこれらの5 分の統計情報を過去1 日のテーブルに保管します。15 個の20 秒のリアルタイム統計を一つの5 分の統計情報に変える手順は、ロールアップと呼ばれています。

またvCenter Server データベースに保管される統計情報には、いくつかの収集頻度があり、5 分の統計情報にロールアップするのと同じように、バックグラウンドでより大きな収集頻度の統計情報にロールアップするために、定期的にストアドプロシージャを実行します。

・過去1 日の統計ロールアップ手順は、5 分の統計情報を30分の統計情報に集約するために、30 分毎に動作します。
・過去1 週間統計ロールアップ手順は、30 分の統計情報を2時間の統計情報に集約するために、2 時間毎に動作します。
・過去1 ヶ月統計ロールアップ手順は、2 時間の統計情報を1日の統計情報に集約するために、1 日毎に動作します。

vSphere Client のパフォーマンスタブで詳細ボタンを選択し、チャートオプションを変更することにより、過去の統計情報を見ることができます。この場合、データベースから統計データを受け取ることになります。

vCenter Server には、統計サブシステムのために保存期間と統計レベルの2つのキーとなるセッティングがあります。

・保存期間: これは、統計情報をデータベースに保存する期間を指定します。データは保存期間よりも古い場合には、期限切れとみなされ、データベースから削除されます。

-1 日:5 分毎の統計情報は、1 から5 日保存されます。
-1 週間:30 分毎の統計情報は、1 週間保存されます。
-1 ヶ月:2 時間毎の統計情報は、1 ヶ月保存されます。
-1 年:1 日毎の統計情報は、1 から5 年間保存されます。

・統計レベル: 一般的には、レベルが高いほど、より詳細な統計情報の取得が可能であり、データベースに保存される容量が大きくなります。

-レベル1:最小限の詳細統計レベルであり、CPU 、メモリ、ネットワークの使用率のような最も重要な統計情報が含まれます。
-レベル2 :レベル1に比べ、より詳細な統計情報が含まれます。
-レベル3 :インスタンスごとの統計情報が含まれます。例えば、CPU 毎のホストのCPU 使用率
-レベル4 :最も詳細であり、他のすべての統計レベルが含まれます。

null
図2. 各統計レベルの保存期間を指定するダイアログボックス
今回はvCenter Server データベースの改善ポイントの概要をご紹介させていただきました。その2 では、より具体的な改善内容、その3では、データベースパフォーマンスのためのベストプラクティスを引き続きご紹介していきます。
関連記事はこちら(その2 その3 )をご覧ください。