VDIの導入に向けて:トラブル解決編

カバー

[!] この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

前回は、VDI運用時に発生したトラブルの内容と調査方法について紹介いたしました。
今回は、どのようにこのトラブルを解決したかを紹介いたします。

前回調査結果からの仮説

前回の調査結果から以下の2点が原因ではないかと推察しました。

  • 仮説1:検証環境ではディスクI/Oの性能が改善された設定でも、本番環境では改善されなかったため、検証環境と本番環境に何らかの環境差異がある

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

仮説の検証

検証環境のVDIと本番環境のVDIの設定情報を、virshコマンドを使用してXMLファイルに出力して比較したところ、検証環境にのみ以下の内容が設定されていました。

<features>
  ...
  <hyperv>
    <relaxed state='on'/>
    <vapic state='on'/>
    <spinlocks state='on' retries='8191'/>
  </hyperv>
  ...
</features>
...
<clock offset='localtime'>
  ...
  <timer name='hypervclock' present='yes'/>
  ...
</clock>

各項目の概要は以下のとおりです。

項目概要
relaxed state='on'watchdog timeout の無効化
vapic state='on'仮想割り込みコントローラの有効化
spinlocks state='on' retries='8191'spinlock機能の有効化
timer name='hypervclock' present='yes'Windows向けのタイマー[hypervclock]の設定

※項目の詳細についてはRed Hat Enterprise Linux 8 仮想化の設定および管理:17.2.2. Hyper-V Enlightenment の有効化を参照

上記の項目は、Windows仮想マシンのパフォーマンス向上に関連する項目であることから、仮想マシンがWindowsであることをOpenStackに認識させるための設定が不足しているのではないかと考えました。そこで、OpenStackのソースコードを「windows」で検索したところ、「os_type == 'windows'」という分岐でWindows仮想マシン固有の設定を行っていることがわかりました。

対象ソース:/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py

# Provide Windows guests with the paravirtualized hyperv timer source.
# This is the windows equiv of kvm-clock, allowing Windows
# guests to accurately keep time.
if os_type == 'windows':
    tmhyperv = vconfig.LibvirtConfigGuestTimer()
    tmhyperv.name = "hypervclock"
    tmhyperv.present = True
    clk.add_timer(tmhyperv)

対応内容

OpenStackではnovaがインスタンス情報を管理しており、instancesテーブルにos_typeカラムがあります。
os_typeにwindowsを設定するために、本番環境で稼働中のVDI/新規で作成するVDIに対して、以下の対応を実施しました。

この対応を実施することで、上記の4項目が全て反映されていることを確認しました。

稼働中のVDI

以下のコマンドにより、インスタンス情報のos_typeをwindowsに更新
※更新後、反映させるためVDIのハードリブートが必要

update instances set os_type = "windows" where uuid = "インスタンスのUUID";

新規で作成するVDI

以下のコマンドにより、利用するイメージにプロパティを追加

glance image-update --property os_type="windows" イメージID

上記対応を実施後、本番環境で稼働中のVDI/新規で作成したVDIに対して、CrystalDiskMarkを用いて測定したところ、ディスクI/Oの性能が向上し、「全体的に動きが遅い」という問題を解消することができました。

対応後の測定結果

対応前後のCrystalDiskMark測定結果は以下のとおりです。
測定項目の名称において、SEQはシーケンシャルテスト、RNDはランダムテストを表し、数値は左から順にブロックサイズ、キューサイズ、スレッドサイズを表します。

Read[MB/s] 測定項目対応前対応後
SEQ1M Q8T12158.64703.5
SEQ1M Q1T1652.01493.8
RND4K Q32T1629.440.9
RND4K Q1T18.414.7
Write[MB/s] 測定項目対応前対応後
SEQ1M Q8T11759.43858.7
SEQ1M Q1T1743.41389.4
RND4K Q32T1623.132.8
RND4K Q1T18.612.4

まとめ

以上、4回に渡ってOpenStack環境で運用しているVDIの導入から構築、トラブル対応まで紹介しました。

新型コロナウィルスの拡大に伴い、業務継続のためのテレワークが急速に普及し、今後もVDIの需要は増加していくと考えられます。

ここまでの記事がVDIの導入を検討中/VDIを運用中の方の参考になれば幸いです。


TOP
アルファロゴ 株式会社アルファシステムズは、ITサービス事業を展開しています。このブログでは、技術的な取り組みを紹介しています。X(旧Twitter)で更新通知をしています。