Home > Blogs > Japan Cloud Infrastructure Blog > 作成者別アーカイブ: Kazuhiro Nishida

作成者別アーカイブ: Kazuhiro Nishida

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

vSphere 5.5 の新機能紹介 – vCenter Serverの新機能

このBlogは、製品出荷前バイナリ及びマニュアルをベースに記載しています。出来る限り正確な情報をお伝えするよう努めておりますが、実際に製品に搭載される機能や表示と異なる可能性があります。あらかじめご了承の上、ご利用下さい。

今回は VMware vCenter Server 5.5(以下vCenter 5.5) の新機能についてご紹介します。
vCenter 5.5 の主な新機能は下記のとおりです。

  1. vCenter Single Sign-On の強化
  2. vCenter Server Appliace 内蔵データベースのスケーラビリティ向上
  3. vCenter 用データベースのクラスターテクノロジーの正式サポート

また新機能ではありませんが、vCenter Server の旧バージョン(4.1/5.0/5.1)からのアップグレード方法について、若干の注意点がありますので、それについても記載します。

1. vCenter Single Sign-On の強化

vCenter 5.1 に同梱されていた Single Sign-on サービス(以下SSO)は、vCenter 5.5 では全面的に刷新され、主にスケーラビリティ、信頼性などが大きく向上しています。
また、従来はデータ格納用として SQL Server など外部データベースシステムが必要でしたが、vCenter 5.5の SSO では外部データベースが不要となり、SSO 内部でデータを保持するよう変更されました。これにともない、SSO マルチサイト構成における、サイト間のデータの同期については、SSO モジュール自身の機能で行えるようになりました(従来は外部データベースのリプリケーション機能が必要でした)。
SSO の機能向上などの詳細については、あらためて別の項でご紹介します。

2. vCenter Server Appliace 内蔵データベースのスケーラビリティ向上

vCenter 5.5 でも引き続き、OSを同梱した仮想アプライアンス形式である vCenter Server Appliace (以下vCSA)を提供します。
従来の vCSA では、内蔵データベース(vPostgres)にて管理可能な ESXi ホスト、仮想マシンなどのオブジェクト数に大きな制限があり、最大 5ホスト、50VMまでのみ対応となっていました。
vCSA 5.5 ではこの制限が大幅に緩和され、最大 100ホスト、3,000VMまで対応できるよう向上しました。従来の数十倍のオブジェクトが管理可能になったわけです。
多くのオブジェクトを管理する環境で使用する際の注意点として、vCSA 5.5 デプロイ時のデフォルトの仮想CPU数、メモリサイズ、仮想ディスクのサイズでは不足する場合がありますので、その場合は仮想メモリ、ディスクサイズ等を増やす必要があります。
管理対象オブジェクト数に対する vCSA 仮想マシンのサイジングのガイドにつきましては、「vCenter Server およびホスト管理ガイド」に記載されていますが、メモリサイズについては下記のとおりです。

VMのメモリサイズ
オブジェクト数
4GB以上 10ホストおよび100VM未満
8GB以上 10から100ホスト、または100-1000VM
16GB以上 100から400ホスト、または1000から4000VM
24GB以上 400ホスト以上、または4000VM以上 (外部DB使用時)

内蔵データベース上にこれらのオブジェクトの情報を格納する場合は、vCSA 仮想マシンに仮想ディスク(VMDK)を別途追加する必要がある場合があります。仮想ディスクの追加方法につきましては、下記ナレッジベースを参照ください。
Increase the disk space in vCenter Server Appliance (2056764) ” (英語)
http://kb.vmware.com/kb/2058187

内蔵データベースに情報を格納する場合は vCSA 仮想マシンのディスク使用量が徐々に増加していきますので、ディスクの残り容量が枯渇していないかどうか、定期的に監視することを強く推奨します。
vCSA 仮想マシンのディスク使用率は、vCSA の管理ウェブコンソール(https://<vCSAのFQDN>:5480)にて監視することが可能(vCenter Server タブ > Summary リンク: 右図参照)ですが、より利便性を高めるために、自動で監視しアラートを通知するためのガイドを提供しています。設定方法につきましては、下記のナレッジベースを参照ください。
Monitor vCenter Server Appliance database disk usage (2058187) ” (英語)
http://kb.vmware.com/kb/2058187

3. vCenter 用データベースのクラスターテクノロジーの正式サポート

vCenter 5.5(Windows 版および vCSA)にて Oracle などの外部データベースを使用する場合、それらのデータベースシステムで利用可能な高可用性テクノロジー(Oracle RAC など)を、 vCenter Server 用データベースとして正式サポートするようになりました。サポートするクラスターテクノロジーの製品名およびバージョン等につきましては、弊社ナレッジベースにて提供する予定です。

4. 旧バージョンからのアップグレード

vCenter 5.1 から vCenter のサービスは、Single Sign-On, Inventory Service, vCenter の3つのモジュールに分割され、それぞれ別のシステムにインストールすることが可能になっています。また Web Client を利用するためには、さらに Web Client Service をインストールする必要があります。
vCenter 5.1 以降では、vCenter をインストールする場合、Simple Install、Custom Installの二つの方法が利用可能です。前者は、SSO、Inventory Service、vCenter を同一システムに一括してインストールする方法です。後者はそれぞれのサービスを別々のシステムに個別にインストールする場合に使用します。
vCenter 5.5 でもSimple Install、Custom Installのそれぞれが利用可能ですが、vCenter の旧バージョンからアップグレードする場合は、それぞれのモジュールのインストール場所およびアップグレード順序についても考慮点があります。
特に注意しなければならないのは、アップグレード順序で、下記の順番でアップグレードする必要があります。

  1. SSO
  2. Web Client
  3. Inventory Service
  4. vCenter

アップグレード元 vCenter のバージョン、および個々のモジュールの配置場所により、アップグレードの方法が異なりますので、下図を参照下さい。

vCenter 5.5 へのアップグレードについては、弊社ナレッジベースに詳細がありますので、そちらを参照ください。
Upgrading to vCenter Server 5.5 best practices (2053132) ” (英語)
http://kb.vmware.com/kb/2053132

仮想化基盤の運用管理の課題を解決する

みなさん初めまして。クラウド製品担当スペシャリストの西田和弘と申します。私の担当は、vSphereのような仮想化プラットフォームだけでなく、vCloud Suiteのようなクラウド基盤およびvCenter Operations Suiteのような運用管理までと、幅広い製品をカバーしています。
業務上多くのお客様とお会いする機会がありますが、仮想化基盤導入後の運用管理フェーズの状況をお聞きするたびに、多くのお客様に共有した課題があるということが分かってきました。
そのような共通の運用管理の課題の例を4つほど挙げてみます。

  1. パフォーマンスの劣化を防止したい
    仮想化基盤では、同一サーバーハードウェア(VMwareではホストと呼ぶことが多いです)上で多数の仮想マシン(以下VM)が同時に稼働しますので、特定のVMがホストのリソースを独占して利用することができず、他のVMとリソースを共有します。したがって個々の仮想マシンが常に最大のパフォーマンスを発揮できるとは限らないので、仮想化基盤では特にパフォーマンスの監視には注意が必要となります。
  2. 統合率を向上させたい
    仮想化基盤導入のもっとも大きく、目に見えるメリットは「コストの削減」です。ホスト1台あたりのVM数が多い、つまり統合率が高いほど、ホストの台数を削減でき、より大きなコストを削減することが可能です。
    もちろん無限にVMを搭載できるわけでないので、「どの程度まで搭載できるか」が問題になります。これはなかなかむずかしい問題で、1.のようにパフォーマンスの劣化を防止つつ統合率を上げるためには、微妙なバランスが必要となります。
  3. リソースの無駄遣いをなくしたい
    これは2.とも関連しますが、仮想化基盤上では、個々のVMにたいし必要な仮想CPU数(以下vCPU)、メモリサイズ(vMEM)を設定した上で展開します。したがってvCPU数、vMEMサイズが大きいほど物理リソースを多く消費することになり、結果として統合率が低下し、コストが増大してしまいます。
    個々のVMにたいして、vCPU数、vMEMサイズの設定値は、仮想化基盤の管理者が一律に決めるのではなく、VMサービスの利用を管理者に申請する人が指定するケースがほとんどです。基盤管理者としては不必要に大きなサイズを設定してリソースの無駄遣いをすることは避けたいと考えていますが、「申請されたサイズ」が本当に必要かどうか不明であるため、しかたなく申請値のまま設定しなければならないことが多いようです。
  4. 将来のリソース使用状況を予測し、ハードウェアを計画的に導入したい
    仮想化基盤はとても便利なので、コスト以外にも多くのメリットがあることに気がつく管理者は多いと思います。便利になり簡単にシステムを追加できるために、すぐにハードウェアリソースが足りなくなってしまうという副作用があります。これは便利さのコインの裏表のような関係ですが、足りなくなることを前提に、程度増加量を予測して計画的にハードウェアリソースの増強を行いたいという声を多く聞きます。

上に挙げた例の他にも共通の課題はありますが、実はこれらの課題そのものにも共通性があります。それはいずれも「VMware vCenter Operations Management Suiteで解決することが可能」ということなのです。
vCenter Operations Suite(以下vCOps)については、仮想環境の運用管理ツールということでご存じ方もいらっしゃると思いますが、「運用管理ツール」というとらえ方はあまり正確でありません。一般的な運用管理ツールというと、システムのイベントやログを監視しアラート発生して管理者に通知するという機能を想像しますが、vCOpsの主要機能はそれだけではないからです。
vCOpsの主要機能は、まさに前述したように、「仮想化基盤における運用管理上の課題を解決できる」ということなのです。
次回以降のブログにて、vCOpsにて解決可能な課題とその方法について、順次紹介していきます。

  1. 仮想化基盤のパフォーマンスを監視し、性能の劣化を防止する
  2. パフォーマンスを犠牲にしないで、統合度を向上させる
  3. リソースの無駄遣い状況を調べ節約する
  4. 基盤の効果的な監視を行い、過剰なアラートを防ぎ、本当に必要な場合のみを知らせる
  5. ハードウェアの増強を計画的に行う
  6. トラブルが発生する前に、未然に防止する
  7. システム構成管理台帳のメンテナンスを自動化し、不測の事態に対応する
  8. 過去にさかのぼってパフォーマンスをレポートを作成する