はじめに

前回は、OpenStack上でのVDI環境の構築について紹介いたしました。
今回は、VDI運用時に発生したトラブルの内容と調査方法を、ご紹介いたします。

トラブル内容

VDIの運用を開始した当初は特に性能的な問題は発生していませんでしたが、VDIの利用者増加に伴い、複数の利用者から「全体的に動きが遅い」との報告を受けたため、その原因調査を行いました。

調査作業

VDI及びVDIが起動している各コンピュートノードから以下のリソース項目の情報を収集し、特異点がないか確認しました。

• CPU使用率
• ロードアベレージ
• メモリ使用率
• ディスクI/O
• ネットワークトラフィック

１．コンピュートノード

• CPU使用率／ロードアベレージ

  • 調査方法
    • 監視ツール（Hinemos／Zabbix）からのデータとtopコマンドで確認
  • 調査結果
    • CPU使用率の上昇はあったが、恒常的に使用率が高い現象は確認されなかった
    • VDI利用者から動きが遅いと報告のあった時間帯でも、CPU使用率やロードアベレージが高い現象は確認されなかった

• メモリ使用率

  • 調査方法
    • 監視ツール（Hinemos／Zabbix）からのデータとtop／freeコマンドで確認
  • 調査結果
    • メモリ使用率が高い現象は確認されなかった
    • VDIのメモリ使用率は、topコマンドでは、固定的に表示されるため、コンピュートノードからはメモリ使用状況はわからなかった

• ディスクI/O

  • 調査方法
    • 監視ツール（Hinemos／Zabbix）からのデータとvmstatコマンドで確認
      • ローカルディスク：novaのディスクI/O
      • ボリュームディスク：cinderのディスクI/O
  • 調査結果
    • VDI利用者から動きが遅いと報告のあった時間帯のディスクI/Oを確認したが、問題となるような現象は確認されなかった

• ネットワークトラフィック

  • 調査方法
    • 監視ツール（Hinemos／Zabbix）からのデータで確認
  • 調査結果
    • 物理的に確保しているネットワーク帯域に比べ、十分な余裕があった

２．VDI

各コンピュートノードに調査用のVDIを起動させて定期的にCPU／ディスクI/Oのベンチマークテストを実施、ベンチマーク結果／タスクマネージャー／パフォーマンスモニタから情報を収集し、特異点がないか確認しました。
また、動きが遅いと報告のあったVDIについては、タスクマネージャー／パフォーマンスモニタから情報を収集し、特異点がないか確認しました。

• 調査結果
  • 動きが遅くなるタイミングでCPU使用率が瞬間的に高い現象と、ディスクI/Oの性能が低下している現象が確認された

原因特定へのアプローチ

調査時点では、動きが遅くなるタイミングでCPU使用率の瞬間的な上昇とディスクI/Oの性能が低下している現象が確認されました。そこで、CPU使用率とディスクI/Oについて、更に観点を追加して調査を行いました。

１．CPU使用率

stressコマンドでCPUに負荷を掛けた状態で、コンピュートノードとVDIのCPU使用率の増加傾向と、ファイルの転送速度を確認しました。

• コンピュートノードのCPUに負荷を掛けた状態

  • コンピュートノード上のCPU使用率が100%となる
  • VDI上のCPU使用率は100%とはならない

• 複数のVDIのCPUに負荷を掛けた状態（VDIへのCPU割り当て数をコンピュートノードの論理CPU数を超えるように設定）

  • コンピュートノード上のCPU使用率が100%となる
  • VDI上のCPU使用率が100%となる
  • 負荷の掛かっているVDIにファイルを転送したところ、負荷なしの時に比べ転送速度が80％低下した

上記の検証で発生したファイル転送速度の低下は、同じCPUを利用する複数のVDIからの処理要求がコンピュートノード上のCPUで同時に処理できる上限を超過したため、CPUで処理待ちが発生したためと考えられます。しかし、前述の調査時点ではCPU使用率が100%となっているタイミングが存在しないことから、VDIの性能劣化は上記とは別の事象であると考えられます。

以上より、現状で報告されているVDIの性能劣化については、CPUは主たる要因ではないと考えられます。

２．ディスクI/O

ディスクI/Oの性能について、以下の3つの観点で比較しました。

１．コンピュートノード、Linuxインスタンス、VDIでディスクI/Oを比較

• コンピュートノードとLinuxインスタンスでは、ほぼ同程度のディスクI/Oとなった

• VDIはLinuxインスタンスの30～40%程度のディスクI/Oしかなかった

２．イメージタイプが異なるVDI（qcow2タイプとrawタイプ）でディスクI/Oを比較

• rawタイプの方が30～50%程度、ディスクI/Oは向上した

• rawタイプの方が10倍程度、ファイルサイズが増大した

３．ioモードとキャッシュモードの設定でディスクI/Oを比較

• kvmのioモードは、「native」／「threads」／「default」／「設定なし」 の4パターン、キャッシュモードは、「directsync」／「writethrough」／「none」／「writeback」／「unsafe」 の5パターンがある

  • ioモードはデフォルト設定である「設定なし」と、「native」について検証した
  • キャッシュモードはデフォルト設定である「none」と、「writethrough」／「writeback」について検証した

• 測定にはCrystalDiskMarkを使用した

＜検証パターン＞

キャッシュモード	ioモード：設定なし	ioモード：native
none	パターンA（トラブル発生時の設定）	パターンD
writethrough	パターンB	未検証
writeback	パターンC	未検証

＜検証結果＞

• 検証環境において、キャッシュモードを「none」から「writethrough」または「writeback」に変更することで、性能が改善した【パターンA→B/C】
• 検証環境において、ioモードを「設定なし」から「native」に変更することで、性能が改善した【パターンA→D】
• 本番環境において、一部のVDIのキャッシュモードを「writethrough」または「writeback」に、ioモードを「native」に設定してディスクI/Oを測定したが、改善しなかった

測定項目の名称において、SEQはシーケンシャルテスト、RNDはランダムテストをあらわし、数値はブロックサイズ、キューサイズ、スレッドサイズを表しています。

Read[MB/s]　測定項目	パターンA	パターンB	パターンC	パターンD
SEQ1M Q8T1	23.07	7962.51	7496.53	37.75
SEQ1M Q1T1	21.05	6080.71	6000.58	27.64
RND4K Q32T16	0.59	325.05	351.81	0.43
RND4K Q1T1	0.23	78.55	79.25	0.22

Write[MB/s]　測定項目	パターンA	パターンB	パターンC	パターンD
SEQ1M Q8T1	39.47	8.60	178.13	47.77
SEQ1M Q1T1	45.42	9.14	187.65	60.56
RND4K Q32T16	0.98	0.49	121.52	0.72
RND4K Q1T1	0.78	0.28	57.76	0.66

• rawタイプの方がディスクI/Oは向上するが、rawタイプの場合はファイルサイズが大きくなり過ぎるため、本件に対する対策には適用できない

• LinuxインスタンスとVDIでディスクI/Oが明らかに異なるため、何か設定が不足している、または設定が誤っている可能性がある

• 検証環境では改善された設定でも、本番環境においては改善されなかったため、検証環境と本番環境に何らかの環境差異がある

以上より、現状で報告されているVDIの性能劣化については、ディスクI/Oに関連するkvmの設定内容に問題があるのではないかと考えられます。

次回予告

次回は、上記の検証結果を踏まえ、どのようにこの問題を解決したかをご紹介いたします。