owned this note   changed 4 years ago  
Linked with GitHub

QEMU容錯開發經驗談-管理及網路效能調校 - 曹伯瑞

tags: COSCUP2021 Advance zh-tw COSCUP2021 System Software TR309

歡迎來到 https://hackmd.io/@coscup/2021 共筆

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

點擊本頁上方的 開始用 Markdown 一起寫筆記！
手機版請點選上方 按鈕展開議程列表。

Slido: https://app.sli.do/event/zgxzodts

請從這裡開始

QEMU-KVM FT / Cuju 簡介

Make Libvirt/OpenStack Support Cuju FT

  • libvirt 簡化虛擬機器啟動等控制生命周期的操作方式
    OpenStack 可稱為雲端作業系統，可管理網路、運算結點等
  • libvirt 與 Cuju 版本 QEMU/KVM 初步整合會使 virsh 指令 crash，由於 libvirt 建立測試 VM 產生 QEMU Binary Information File (紀錄 QEMU 版本與能力)；而 libvirt 使用 -none 作 machine type 來啟動測試 VM，會導致用 cuju 修改的程式碼用 kvm->vcpus[0] 這類的時候會得到 null pointer，修正後 libvirt 就能正常與 QEMU 執行指令。

libvirt 部份

  • Live Migration: virsh migrate --live vm01 qemu+ssh://dest-host/system
    Cuju FT: virsh migrate --live --cuju vm01 qemu+ssh://dest-host/system
    這個指令需要做：建立 backup VM(QEMU command -incoming port, ftmode)、設定 Primary capability (migrate_set_capability cuju-ft on)、然後 在 Primary 主機上執行 migrate -c。

  • libvirt 定義的 live migration 分成 5 個階段：

    • Begin (parse command parameter)
    • Prepare (Create backup/destination VM on backup/destination side)
    • Perform (Execute live migration command)
    • Finish (Make backup/destination VM running)
    • Confirm (Stop primary/source VM)

  • 在建立容錯連線時 Finish、Confirm 兩階段不可執行，因此透過在 Cuju mode 下跳過 暫停 Primary side VM、等待Live Migration結束及停止 等方式建立容錯連線

  • 初步測試發現使用 SPICE Display 時會 crash，因為 SPICE 會更新 vga.vram 和 qxl.vrom，而 Cuju 會標記並備份導致發生問題，因此透過不標記 VROM/VRAM dirty 的方式解決

  • Channel SPICE 則會導致 VM failover 時 crash

    • 因為 VM start 時會 free 掉先前建立的 timer；當在 live migration 時因為只有 1 個 load_device 和 1 VM start 而無問題，而 FT 時會有 3個 load_device(init, first snapshot, failover)，會導致 free 錯 timer
    • 解決方法為當 init timer 時，如果已經有 timer 則先 free 掉再新建。

  • 此外也有遇到 AppArmor 造成的權限問題

OpenStack 部份

  • 在 nova 中新增 FT 支援的指令 (進入FT、顯示狀態、回到無FT 或觸發 failover 的狀態)

  • nova 指令皆為 nova-client 接收後經 HTTP 傳到 nova-controller 驗證正確性後，用 RPC 傳送到 compute 執行實際指令

  • pre-live migration 部份只需改變 migraiton 參數即可

  • post-migration 則將所有要釋出原本 source 資源資訊的動作通通都延到 failover 之後才做

  • 需建立 controller 上的 API parameter check rule、更新 nova state 資料庫(因 nova 會維護所有 VM 狀態)

容錯模式下 TCP 會遇到的問題以及如何最佳化

容錯為保護機器對外狀態一致，引入了 buffer output 機制，產生額外延遲、讓 TCP 誤判 RTT 時間，無論 outgoing/incoming 都會被計算成壅塞，讓 TCP 速度無法改變

TCP Proxy

  • 設計一個 TCP Proxy 來降低不必要的 congestion control 帶來的影響

  • 在每個 TCP 連線間建立 transparent proxy，把連線分成兩段 (client-proxy、proxy-VM)，連線狀態不會互相干擾，透過 packet queue 交換資料，並於每次備份周期時備份兩邊的 TCP 狀態以便還原

  • 需有 IPC Handler 處理 Cuju 容錯階段的不同狀態(snapshot, flush, failover)訊號

    • 發生了TCP Proxy收到順序與Cuju發出不符的情形，因 IPC 跟其他連線走同 thread 導致資源爭奪。
    • 重新設計了 IPC 架構以使其獨立程式運作，透過 shared memory(SHM) 交換資料，保證 IPC Handler 不會收到一般 TCP 影響

  • 修復輸出 TCP 連線

    • 將 incoming/outgoing seq drop/rollback 再繼續傳輸

  • 10G 網路下 degradation 小於 5%，非常接近無 FT 保護的原始速度，相對有 FT 保護原始速度有大幅(數倍)提升

Q&A

想請問一下跟 OpenStack 整合的 code 是否有 open source? Google 了一下都沒有找到，也沒有在 upstream 看到有相關要整合的 spec 提出。

  • 正在評估怎麼樣去跟社群版本整合，還在評估

能不能在 ARM64 平台像是 RPi4 上執行？

  • 基於 x86 KVM/QEMU port，目前不能直接執行；
    目前 ARM KVM 已經有了，可以看看能不能移植

Q1: 是否有任何的 upsteam 計畫，以減少後續 KVM/QEMU/libvrit 進版時的 porting effort? Q2: 效能耗損除了量測 latency, 在 network throughput 是否也能維持低耗損？

  1. 進板比較麻煩的部份是 KVM，但 QEMU/libvirt 部份就還好，但目前沒有其他跟進或進板計劃，可能進板後原有的效能改善方式會失效，暫時以效能考量優先。

  2. buffer output 造成 TCP 效能損失，可透過前面所提 TCP Buffer Proxy(?) 改善

Cuju 最大的 production deployment 是哪裡？

  • 有 deploy 在智慧電網/智慧工廠裡的系統，未來也有機會在類似軍方單位

Qemu 進版時，Cuju 移植到新版成本如何？

  • 如前面問題，porting 到新版最大麻煩在 KVM，QEMU 部份還好，因為大部份是用標準的 Live migration function call

有沒有參考過 DMTCP、CRIU 這類其他外面著名的開源 Live Migration 機制

  • 有，CRIU 有參考過、算是 container live migration 的機制，裏面有一部份實用的機制、像轉移後讓網路快速恢復的部份。CRIU 算是 process 的 migration，讓 migration 一次的成本蠻高，比較難做成容錯。
Select a repo