[!] この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
前回は、VDI運用時に発生したトラブルの内容と調査方法について紹介いたしました。
今回は、どのようにこのトラブルを解決したかを紹介いたします。
前回調査結果からの仮説
前回の調査結果から以下の2点が原因ではないかと推察しました。
-
仮説1:検証環境ではディスクI/Oの性能が改善された設定でも、本番環境では改善されなかったため、検証環境と本番環境に何らかの環境差異がある
-
仮説2:LinuxインスタンスとVDIでディスクI/Oの性能が明らかに異なるため、何か設定が不足している、または設定に誤りがある
仮説の検証
検証環境のVDIと本番環境のVDIの設定情報を、virshコマンドを使用してXMLファイルに出力して比較したところ、検証環境にのみ以下の内容が設定されていました。
各項目の概要は以下のとおりです。
項目 | 概要 |
---|---|
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
対応内容
OpenStackではnovaがインスタンス情報を管理しており、instancesテーブルにos_typeカラムがあります。
os_typeにwindowsを設定するために、本番環境で稼働中のVDI/新規で作成するVDIに対して、以下の対応を実施しました。
この対応を実施することで、上記の4項目が全て反映されていることを確認しました。
稼働中のVDI
以下のコマンドにより、インスタンス情報のos_typeをwindowsに更新
※更新後、反映させるためVDIのハードリブートが必要
新規で作成するVDI
以下のコマンドにより、利用するイメージにプロパティを追加
上記対応を実施後、本番環境で稼働中のVDI/新規で作成したVDIに対して、CrystalDiskMarkを用いて測定したところ、ディスクI/Oの性能が向上し、「全体的に動きが遅い」という問題を解消することができました。
対応後の測定結果
対応前後のCrystalDiskMark測定結果は以下のとおりです。
測定項目の名称において、SEQはシーケンシャルテスト、RNDはランダムテストを表し、数値は左から順にブロックサイズ、キューサイズ、スレッドサイズを表します。
Read[MB/s] 測定項目 | 対応前 | 対応後 |
---|---|---|
SEQ1M Q8T1 | 2158.6 | 4703.5 |
SEQ1M Q1T1 | 652.0 | 1493.8 |
RND4K Q32T16 | 29.4 | 40.9 |
RND4K Q1T1 | 8.4 | 14.7 |
Write[MB/s] 測定項目 | 対応前 | 対応後 |
---|---|---|
SEQ1M Q8T1 | 1759.4 | 3858.7 |
SEQ1M Q1T1 | 743.4 | 1389.4 |
RND4K Q32T16 | 23.1 | 32.8 |
RND4K Q1T1 | 8.6 | 12.4 |
まとめ
以上、4回に渡ってOpenStack環境で運用しているVDIの導入から構築、トラブル対応まで紹介しました。
新型コロナウィルスの拡大に伴い、業務継続のためのテレワークが急速に普及し、今後もVDIの需要は増加していくと考えられます。
ここまでの記事がVDIの導入を検討中/VDIを運用中の方の参考になれば幸いです。