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

###### tags: `COSCUP2021` `Advance` `zh-tw` `COSCUP2021` `System Software` `TR309`

{%hackmd kra72OaxRTiBzdV8Y4GMKA %}

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

> 請從這裡開始

## QEMU-KVM FT / Cuju 簡介
- 可參考網站的簡介、 paper 和 installation guide：
https://cuju-ft.github.io/cuju-web/home.html
- 可避免[災難](https://youtu.be/mi9gjvGNpd0)發生服務中斷
- 透過減少傳輸時間、減少快照時間和額外複製的時間改善受保護服務的效能

## Make Libvirt/OpenStack Support Cuju FT
- [libvirt](https://libvirt.org/) 簡化虛擬機器啟動等控制生命周期的操作方式
[OpenStack](https://www.openstack.org/software/) 可稱為雲端作業系統，可管理網路、運算結點等
- 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 一次的成本蠻高，比較難做成容錯。