ライブマイグレーションにおけるサブページ書き込み保護の評価
•Download as PPTX, PDF•
0 likes•54 views
小澤 洋介, 品川 高廣． ライブマイグレーションにおけるサブページ書き込み保護の評価． 第151回システムソフトウェアとオペレーティング・システム研究会，オンライン，2021年3月． http://id.nii.ac.jp/1001/00209631/
Recommended
Recommended
More Related Content
More from Shinagawa Laboratory, The University of Tokyo
More from Shinagawa Laboratory, The University of Tokyo (11)
ライブマイグレーションにおけるサブページ書き込み保護の評価
- 1. ライブマイグレーションにおける サブページ書き込み保護の評価 〇小澤洋介 品川高廣 東京大学 2021/4/19 1 第151回 システムソフトウェアとオペレーティング・システム研究会 2021年3月2日
- 2. アウトライン 1. 背景 ◦ ライブマイグレーション ◦ 既存の細粒度化手法 2. 提案手法 3. 実装 4. 評価 5. まとめ 2021/4/19 2
- 4. 仮想マシンを動作したまま 他物理マシンへ移送 ユースケース ◦ ハードウェア/ソフトウェア メンテナンス ◦ 負荷分散 2021/4/19 4 [1] Christopher Clark et al, Live migration of virtual machines, In Proc. NSDI 2005, p.273-286, May 移行元物理マシン 移行先物理マシン VM VM VM VM VM ライブマイグレーション[1]
- 5. プレコピーマイグレーション 移行元から移行先へ複数回のメモリコピー 各イテレーションでの転送メモリ量の削減は重要 ◦ ネットワーク負荷，総マイグレーション時間の削減に直結 ◦ 転送メモリ量が大きすぎるとマイグレーションが完了できないことも 2021/4/19 5 メモリ メモリ 移行元物理マシン 移行先物理マシン
- 8. 01101101 01101101 01101101 ページの一時保存による細粒度化 転送時にページそのものやページのハッシュを保存 XBZRLE: 再転送時に前回転送時との差分を計算し，差分圧縮を行い転送 2021/4/19 8 メモリ メモリ 移行元 移行先 01110101
- 10. サブページ書き込み保護 当分割されたサブページへの書き込み保護 ◦ 保護されたサブページへの書き込みは ページフォルトを発生 書き込み検知は目的外 ◦ 本来はメモリ保護用 2021/4/19 10 書き込み不可 書き込み可 通常ページ サブページ
- 14. メリット/デメリット 2021/4/19 14 通常ページ 書き込み検知 通常ページ 書き込み検知 + 一時保存 サブページ 書き込み検知 転送メモリ量 ✗粗粒度 書き込み検知 ✓ビット単位で 比較 ✓細粒度 書き込み検知 余剰リソース使用 ✓ ✗メモリとCPU ✓ 仮想マシンの 性能劣化 ✓CPUが処理 余剰リソースに 依存 ✗ページフォルト を発生
- 15. 実装 2021/4/19 15
- 16. 実装 Intel EPT-Based Sub-page write permission (SPP)[3] ◦ 128Bサブページ ◦ 4KB通常ページを32分割 実装されたCPUを入手できず → IA-32エミュレータのBochs[4]を使用 2021/4/19 16 https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf [3] http://bochs.sourceforge.net/ [4]
- 17. 2021/4/19 17 仮想マシン KVM QEMU ゲストOS Bochs 書き換え サブページ フォルト ハンドラ 1 1 0 1 1 0 1 1 1 1 0 0 0 0 0 0 反映 サブページ 転送システム 書き込み情報の取得 仮想CPU 仮想メモリ 書き込み保護 変更部位 凡例 変更部位 変更なしの部位 書き込み ネステッドページテーブル サブページ フォルト 命令取得 システム概要
- 18. 2021/4/19 18 仮想マシン KVM QEMU ゲストOS Bochs 書き換え サブページ フォルト ハンドラ 1 1 0 1 1 0 1 1 1 1 0 0 0 0 0 0 反映 サブページ 転送システム 書き込み情報の取得 仮想CPU 仮想メモリ 書き込み保護 変更部位 凡例 変更部位 変更なしの部位 書き込み ネステッドページテーブル サブページ フォルト 命令取得 システム概要
- 19. 2021/4/19 19 仮想マシン KVM QEMU ゲストOS Bochs 書き換え サブページ フォルト ハンドラ 1 1 0 1 1 0 1 1 1 1 0 0 0 0 0 0 反映 サブページ 転送システム 書き込み情報の取得 仮想CPU 仮想メモリ 書き込み保護 変更部位 凡例 変更部位 変更なしの部位 書き込み ネステッドページテーブル サブページ フォルト 命令取得 システム概要
- 20. 2021/4/19 20 仮想マシン KVM QEMU ゲストOS Bochs 書き換え サブページ フォルト ハンドラ 1 1 0 1 1 0 1 1 1 1 0 0 0 0 0 0 反映 サブページ 転送システム 書き込み情報の取得 仮想CPU 仮想メモリ 書き込み保護 変更部位 凡例 変更部位 変更なしの部位 書き込み ネステッドページテーブル サブページ フォルト 命令取得 システム概要
- 21. 評価 2021/4/19 21
- 22. 評価手法 1. 従来の4KiB ページ単位の書き込み検知手法 2. 4KiB ページ書き込み検知と QEMUに標準搭載のページ一時保存(XBZRLE)を 組み合わせた手法 3. Intel SPPによるサブページ書き込み検知手法 2021/4/19 22
- 23. 実験設定 2021/4/19 23 仮想マシン割り当てメモリ 1GiB ネットワークバンド幅 1Gbps ワークロード Idle Kernel compile redis + YCSB (workloada～workloadf) SPECCPU (xxx.*_r) XBZRLE一時保存メモリサイズ 512MiB 最大イテレーション数 20 ストップコピー移行条件 転送時間<300ミリ秒
- 26. 疑似マイグレーション 2021/4/19 26 Bochs 仮想マシンを停止し 次イテレーションに かかる時間を推定 転送メモリ量 ネットワークバンド幅 1GB/1Gbps = 8s ハイパーバイザ 仮想メモリ ゲストOS
- 27. 8s ×4.8GIPS = 38.4GI 疑似マイグレーション 2021/4/19 27 Bochs 次イテレーションで 実行される命令数を推定 転送時間 × 実機上で動作する仮想マシンのIPS ハイパーバイザ 仮想メモリ ゲストOS
- 33. 書き込み命令分析 0xffffffff81ab27a7 0xffffffff811b3a23 0xffffffff812da15d other instruction multi instructions 2021/4/19 33 ほとんどが ページゼロクリア関数内の rep stosq命令によるもの
- 39. CPUオーバーヘッド 2021/4/19 39 Lower is better メモリを転送する準備として QEMU で使用するフォーマットに整形するのに要した命令数
- 42. まとめ 2021/4/19 42
- 45. 2021/4/19 45
Editor's Notes
- ライブマイグレーションにおけるサブページ書き込み保護の評価という題目で東京大学の小澤が発表させていただきます．
- 以下のような流れで説明させていただきます．
- まずはライブマイグレーションについて説明します．
- ライブマイグレーションは，あるホストで実行中の仮想マシンを停止することなく別のホストへと移行する技術です． ハードウェア，ソフトウェアのアップデートの際の一時退避や，負荷分散などに用いられます．
- 現在主流なライブマイグレーションの方式に，プレコピーマイグレーションがあります． この方式では，移行元で仮想マシンを動作させたまま移行先にメモリ内容を転送し，転送中に新たに書き込まれたメモリ内容を再度転送するという処理を，差分が十分に小さくなるまで繰り返します． そして差分が十分に小さくなった段階で移行元で仮想マシンの実行を停止し，最後のコピーを行い，移行先で実行を再開することでダウンタイムを削減します． 各イテレーションでの転送メモリ量の削減は総転送メモリ量の削減につながり，それはマイグレーション時間及びネットワーク負荷の削減に直結します． また，イテレーションを重ねる毎に転送メモリ量が減らなければ，転送メモリ量が閾値を下回ることができず，マイグレーションを完了させることが出来なくなります． このように，プリコピーマイグレーションにおいて転送メモリ量の削減は重要な課題になっています．
- 転送メモリ量の削減手法の一つとして，書き込み検知の細粒度化があります． 現在実用的に使われているライブマイグレーション機構においては，基本的には書き込み検知の粒度はページ単位になっています． これは，書き込み検知が主にCPU のネステッドページングの付随機能であるダーティビットを用いて実装されているためです． しかし，アプリケーションは必ずしもページ全体に書き込みをおこなうとは限らず， 例えば，ダーティビットだけではページの中の実際に書き込まれた部分だけを検知することが出来ないため，4KiBページ全体を転送する必要がある． 書き込み検知の細粒度化を行うことにより，余剰なメモリ転送を排除できると考えられます．
- 続いて既存の細粒度化手法とその問題点について説明します．
- 書き込み検知の細粒度化手法として，ページの一時保存による細粒度化があります． 転送時にページそのものやページの領域ごとのハッシュを保存し，対象ページが再度転送される際に 差分を計算することにより，細粒度での変更検知を行うことができます． QEMUにデフォルトで実装されているXBZRLEという手法では，差分をランレングス圧縮することで転送量の削減を達成しています． しかしこの手法ではページの一時保存にメモリを，差分圧縮の計算にCPUを使用するため，ホストの負荷が高い場合には，仮想マシンの性能に大きな影響を与える可能性があります．
- 提案手法についてお話しします．
- 我々はCPU のハードウェアを利用した書き込み検知の細粒度化の手法として，サブページ書き込み保護による書き込み検知を提案します． サブページ書き込み保護とはページング機構の追加機能であり，従来のページングよりも細かい粒度で書き込み保護をおこなえる機能です． この機能では，従来の通常サイズの「ページ」を，より小さくて同じサイズの「サブページ」に等分割し，個々のサブページに対して個別に書き込み保護を設定することが出来ます． 書き込み保護が設定されたサブページに書き込みが発生した場合，CPU はサブページフォルトを発生します．
- サブページ書き込み保護を用いた書き込み検知について説明します． 前述のように，ハイパーバイザは仮想マシンに割り当てた仮想メモリの各サブページの書き込み権限を個別に設定することができます．
- 書き込み検知開始時に，ハイパーバイザはすべてのサブページに対して書き込み保護を行います． 書き込み保護されたサブページへの書き込みはページフォルトを引き起こし，ハイパーバイザへと処理が手渡されます．
- ハイパーバイザは書き込みが行われたサブページのアドレスを記録し，その領域の書き込み保護を取り除きます． このような流れでサブページ書き込み保護による書き込み検知が可能になります．
- それぞれの手法について再度まとめます． ダーティビットを用いた通常ページでの書き込み検知手法はCPUがビットを自動でセットしてくれるため，仮想マシンの性能劣化はありません． 一方で書き込み検知の粒度は通常ページサイズに限定され，転送メモリ量が大きくなる可能性があります． ページの一時保存はビット単位で比較が可能となり転送メモリ量を削減することができますが，リソース使用量が大きく，余剰リソースが不充分な場合は仮想マシンの性能劣化を招く可能性があります． 我々が提案するサブページ書き込み検知はサブページ単位での書き込み検知により転送メモリ量の削減が可能で，余剰リソース使用量も小さく抑えられますが，ページフォルトのハンドリングが必要なため仮想マシンの性能劣化を引き起こします．
- 実装についてお話しします．
- 本研究では，サブページ書き込み保護を提供するCPU のアーキテクチャとしてIntel SPP を使用しました． 一方でSPPが実装されたCPUを入手できなかったため，動作環境にはSPP のエミュレーションが実装されたx86 エミュレーターであるBochs [20] を使用しました．
- システムの全体像はこのようになっています． 青色の部分が今回変更を加えた部位になります．
- Bochsについては，TLBの実装に関しSPPの情報がキャッシュされないというバグを見つけたため，正しくキャッシュされるように修正を行いました．
- サブページ書き込み検知を実装する仮想マシンモニタのベースとしては，Linux 5.5.7 のKVM にSPP 対応のパッチを適用したものを使用しました． このパッチにより，KVMはSPP の有効化やSPP ページテーブルの構築，EPT violation及びSPP 関連イベント発生時のハンドリングをおこなうことができます． このハンドリング処理を書き込み検知を目的としたものに修正しました． また，オーバーヘッドの削減を目的として，サブページフォルトが発生したときの命令を取得する機能を実装しました． 命令の取得は，サブページフォルト時に仮想CPU の命令ポインタの値を取得し，仮想マシンのメモリからそのアドレスのメモリの値を読み取ることで実現しました． この命令取得機能を用いたオーバーヘッドの削減については後程説明します．
- マイグレーションの機能はQEMU 4.2.50をベースに実装を行いました． 書き込みがおこなわれたサブページをQEMUで取得するために，KVM と連携して指定したサブページの書き込み許可ビットの値をioctlで取得する仕組みを実装しました． また，転送時のメタデータ形式についてもサブページ単位でのアドレス記述が可能となるようにメタデータとして新たに1 バイトの値を追加する変更を行いました．
- 評価に移ります．
- 本実験では従来の4KiB ページ単位の書き込み検知手法，及びそれとQEMUに標準搭載されたページの一時保存による細粒度化手法であるXBZRLEを組み合わせた手法，そして提案手法であるIntel SPPによるサブページ書き込み検知手法の3つを評価対象としました．
- このような設定で実験を行いました． 仮想マシンのメモリ量は1GB，ネットワークバンド幅は1Gbpsとし，ワークロードはこれらを実行しました．
- Bochsの性能は実機に比べ大きく劣るため，実際にBochs上でマイグレーションを行っても実機での結果とは異なる結果となると考えられます． そこで，時間経過ではなく実行命令数を基準としてメモリ転送量を測定する疑似マイグレーションをおこないました．
- 疑似マイグレーションについて説明いたします． 通常のマイグレーションと同様に，はじめ仮想マシンは動作し，書き込みが行われます． 通常のマイグレーションでは仮想マシンを動作させたまま転送メモリの取得及び転送を行うのですが，
- 疑似マイグレーションでは仮想マシンを一旦停止し，書き込みが行われたメモリを調べます． そして転送メモリ量を集計し，対象となるネットワークバンド幅でこのメモリ量を転送するのに何秒かかるかを見積もります． たとえば転送メモリ量が1GBでネットワークバンド幅が1Gbpsであった場合，転送時間は8秒と見積もられます．
- 続いて，現実の仮想マシンが与えられた転送時間にわたって動作した場合に，何インストラクションを実行できるか見積もります． 事前に集計した各ワークロードにおける秒間の実行インストラクション数，すなわちIPSを見積もられた転送時間にかけることで， 転送中の仮想マシンの実行命令数を見積もることができます．
- この見積もられた命令数を仮想マシンに実際に実行させることで，次のイテレーションでの転送メモリ量を取得することができます． 以上が疑似マイグレーションの流れになります．
- また，仮想マシンの性能劣化については疑似マイグレーション中に発生したsppフォルトの回数に，一回のsppフォルトのハンドリングにかかるインストラクション数をかけることによって 見積もるものとします．
- ワークロードにおいて第二イテレーション時に実行される命令数を計算してBochs 上で再現し，その実行期間内において各4KiB ページ内のうち書き込みがおこなわれたサブページ数の平均を求めた．
- 平均して約1,300 枚の4KiB ページでは1 枚のサブページにのみ書き込みがおこなわれており 約700 枚の4KiB ページでは2 枚のサブページのみ書き込みがおこなわれていることがわかりました． これらは128Bや256Bの転送で十分であり，4KiBページ丸ごと転送する場合と比べ，全体で19.1%の転送量削減が期待できます．
- 一方，4KiB ページ中の全てのサブページに書き込みがおこなわれるケースも約16,000 枚ほどありました． このようなページの存在はページフォルトを増大につながるため，オーバーヘッドの要因となります． このようなページが発生するページフォルトを削減するため，このような書き込みを行うゲストOS の命令を調査しました．
- その結果，多くの4KiBページはLinux カーネル内のclear page rep() というページのゼロクリアをおこなう関数内の，rep stosq 命令であることが分かりました． よって，先ほど述べたKVMのゲスト命令検出機構を用いてrep stosq命令を取得することにより，ページフォルトの回数を削減する最適化を実装しました． 移行の結果はこの最適化を用いた際のもので，この最適化によるオーバーヘッドの減少については後程説明します．
- まず，疑似マイグレーションにおける総マイグレーション時間について示します． 波線より大きい値はマイグレーションが20イテレーション以内に完了しなかったことを示します． 疑似マイグレーションでは転送時間は転送メモリ量をネットワークバンド幅で割ったものとなるため，ネットワーク負荷の削減も示すものになっています． 多くのワークロードにおいて128Bサブページ書き込み検知は，4KiB ページ書き込み検知＋XBZRLE と同等のマイグレーション時間の短縮が実現できることが分かりました． また，SPECCPU の4 つのワークロード（520.omnetdp r, 531.deepsjeng r, 577.xz r,519.lbm r）では，4KiB ページ書き込み検知はマイグレーションを完了出来なかったのに対し，XBZRLE を併用するとそのうちの2 つ（520.omnetdp r, 577.xz r），128B サブページ書き込み検知を用いるとさらに1 つ（531.deepsjeng r）でマイグレーションを完了させられることが分かりました．
- それぞれのマイグレーションについて詳細に見ていきます． こちらは横軸に時間を，縦軸に各イテレーション内での未転送メモリ量をとったグラフになります． 第一イテレーションはメモリ全体の転送を行うため手法ごとの差はありませんが，第二イテレーション以降4KiBページ書き込み検知＋XBZRLEおよび128Bサブページ書き込み検知では転送メモリ量が削減され，結果マイグレーションを完了させられていることが分かります．
- また，一部のワークロードでは，128B サブページ書き込み検知は，4KiB ページ書き込み検知＋ XBZRLE よりもマイグレーション時間を短縮できることが分かった． この557.xz r というワークロードでは，図に示すように，第二イテレーションでは128B サブページ書き込み検知の方が差分が大きかったものの，その後に逆転して結果的に短い時間でマイグレーションが完了していることが分かる． これは，メモリに書き込まれた内容がXBZRLE による差分圧縮が効きにくいものであったためと考えられる．
- また，128B サブページ書き込み検知だけがマイグレーションを完了させられた531.deepsjeng rにおける未転送メモリ量の推移はこのようなものでした． 4KiB ページ書き込み検知ではイテレーションが進んでも転送メモリ量がほとんど削減できていないことや， 4KiB ページ書き込み検知＋ XBZRLE であっても転送メモリ量の削減が効果的に進んでいないこと， 一方で128B サブページ書き込み検知のみが着実にイテレーションごとに転送メモリ量を削減できていることが分かります． このように書き込み頻度が高く差分圧縮も効きにくいワークロードではサブページ書き込み検知が効果的であると分かりました．
- 一方，128B サブページ書き込み検知を用いるとかえって転送メモリ量が増えるワークロードもあった． 図に，519.lbm r の各イテレーション毎の未転送メモリ量の推移を示す． グラフから，4KiB ページ書き込み検知と比べて4KiB ページ書き込み検知＋ XBZRLE では転送メモリ量をやや削減出来ているのに対し，128B サブページ書き込み検知では転送メモリ量がやや増えていることが分かる． これは，転送時にサブページごとにメタデータを付与したため，4KiB ページに比べ転送内容が増えたことが理由として考られる
- 各手法におけるCPU オーバーヘッドを見積もるために，各ワークロード毎に，メモリを4KiB転送する準備としてQEMU で使用するフォーマットに整形するのに要した命令数を測定した． 4KiB ページ書き込み検知の場合は，書き込みがおこなわれたページの情報を取得するioctlの実行や，ページの値がすべてゼロであるかの判定，ページ全体を所定のフォーマットに整形する処理などにかかった命令数である． 4KiB ページ書き込み検知＋ XBZRLE の場合は，それに加えてページの一時保存や圧縮にかかった命令数が含まれる． 図に測定結果を示す．エラーバーは標準誤差を示す． 4KiB ページ書き込み検知の場合と比べて，4KiB ページ書き込み検知＋ XBZRLE では必要な命令数が1.33～175.38倍に増加した． これは，XBZRLE がバイト単位での値の比較を含む圧縮操作に多数の命令を要するためであると考 えられる． 128B サブページ書き込み検知も1.22～15.84 倍に命令数が増加しているが，これはサブページを扱うためにページ毎の処理が増加したためと考えられる． しかし，いずれも場合でもXBZRLE の場合と比べて命令数を低く抑えられている．
- メモリに対するオーバーヘッドを見積もるために，第二イテレーション開始時における，ホストマシン，すなわちBochs全体におけるメモリ使用量をfree コマンドを用いて測定した 4KiB ページ書き込み検知＋ XBZRLE では，最大512MiBのメモリをページの一時保存に使用するように設定しているため，ホストマシンにおけるメモリ使用量が1.21～1.85倍に増加することが分かった 一方，128B サブページ書き込み検知によるメモリ使用量の増加はほとんど見られなかった．
- また，先ほど述べた手法で計算したオーバーヘッドを図に示します． idle 状態の場合には，オーバーヘッドが200.74%と大きい値を示したが，もともと負荷のかかっていない状態であるため，このオーバーヘッドはあまり問題にならないと考えられる 他のワークロードを見ると，主に4KiB ページ書き込み保護ではマイグレーションが終了しなかったワークロードにおいて，比較的オーバーヘッドが大きくなっていることが分かる すなわち，書き込み頻度の高いワークロードでは，SPP のイベントハンドリングのオーバーヘッドが大きくなることを示している． また，ゼロクリア命令の検知による最適化の効果としては，単純に128B サブページ単位で書き込み検知をおこなうとオーバーヘッドが最大80.0%程度であったのに対し，最適化をおこなうことにより最大54.5%程度に削減できることが分かった． 従って，ゼロクリア命令の検知は一定の効果があるものの，さらなる最適化の余地もあると考えられる．
- まとめです
- まとめに入ります． サブページ書き込み保護機構を用いたサブページ書き込み検知のライブマイグレーションにおける有効性について評価を行いました． 全体として4KiBページ書き込み検知＋XBZRLEと同程度の総マイグレーション時間短縮を実現でき， ワークロードによっては提案手法のみがマイグレーションを完了させられることもわかりました．
- 今後の課題としては サブページ書き込み保護をサポートするCPUを搭載した実機マシンを入手し，実機マシン上での性能評価を行うことや， オーバーヘッドのさらなる削減を目的とした，サブページ単位での書き込み予測によるページフォルト回避手法の提案 複数仮想CPUをもつ仮想マシンに本手法を適用した際のメモリ一貫性を保つためのオーバーヘッドの評価などが挙げられます．