知識星球
這就是今天要討論的話題：SR-IOV，一種硬體角度出發的虛擬化解決方案，本文不僅會對這項技術的概念和原理進行介紹，還會結合AWS以及Memblaze的研究來探討SR-IOV在雲端計算資料中心的應用方法、價值和前景。
SR-IOV及虛擬化系統中相關概念
在介紹之前，需要先明確一些SR-IOV相關的概念，一個典型的SR-IOV方案架構如下。
SR-IOV的實現模型
（來源：http://www.pcisig.com/）
System Image（SI），客戶機，或者稱虛擬機器OS。
Virtual Intermediary（VI），虛擬機器管理層，是物理機和虛擬機器的中介，可以是hypervisor或者VMM。（SR-IOV的主要作用就是消除VI對I/O操作的幹預，進而提升資料傳輸效能）。
SR-PCIM，配置和管理SR-IOV功能以及PF/VF的軟體，SR-PCIM可以處理相關的錯誤和實現裝置的整體控制（比如實現電源管理和熱插拔，一個PCIe裝置支援SR-IOV時，SR-PCIM就可以透過熱插入的方式為物理主機新增VF裝置，然後就可以配置VF給虛擬機器使用。）
PF（Physical Function），SR-IOV中的關鍵概念， PF 是 PCIe一種物理功能，每個PF都可以被物理主機發現和管理。進一步講，藉助物理主機上的PF驅動可以直接訪問PF所有資源，並對所有VF併進行配置，比如：設定VF數量，並對其進行全域性啟動或停止。
VF（Virtual Function），PF虛擬出來的功能。一個或者多個VF共享一個PF，其驅動裝在虛擬機器上，當VF分配給虛擬機器以後，虛擬機器就能像使用普通PCIe裝置一樣初始化和配置VF。如果PF代表的是一張物理網絡卡，那麼VF則是一個虛擬機器可以看見和使用的虛擬網絡卡。
一句話解釋SR-IOV
SR-IOV透過將PF分為多個VF為上層虛擬機器使用，相當於虛擬機器繞過VI直接使用PCIe 裝置處理I/O和傳輸資料。
值得一提的是，物理主機啟動時不能簡單的掃描SR-IOV裝置併列舉出所有VF，因為VF沒有完整的PCIe配置空間。可以用Linux PCI熱插拔API動態為物理主機增加VF，然後分配給虛擬機器使用。
SR-IOV實現的價值
傳統虛擬化系統中大量的資源和時間損耗在Hypervisor（或者VMM）軟體層面，PCIe裝置的效能優勢因此無法徹底發揮。而SR-IOV的價值在於消除這一軟體瓶頸，助力多個虛擬機器實現物理資源共享，同時使得虛擬機器可以使用到NVMe SSD的高效能。
在此我們可以總結得出SR-IOV優勢：
實現SR-IOV之後，VMM把中斷交給虛擬機器處理,而不是VMM處理I/O，提高了效能；
虛擬機器直接和PCIe裝置互動減輕物理主機CPU負擔，使之有能力承載更多虛擬機器；
SR-IOV虛擬化技術可以減少客戶所需PCIe裝置數量，進而節省PCIe插槽；
SR-IOV可以與其他的I/O虛擬化技術進行結合提供一個更加完整的兼具高效能和安全性的解決方案。
以NVMe SSD為例，今天的一塊NVMe SSD容量可以達到十幾TB，而IOPS衝到了100萬，同時有著微秒級的延遲。SR-IOV可以使NVMe SSD直接被上層多個VM所用，SSD的效能優勢也可以直接被上層應用感知到。
可以看到虛擬化和雲端計算都是SR-IOV大顯身手的領域。事實上，我們看到當前走在SR-IOV實踐最前面的，就是雲端計算巨頭AWS。接下來我們也將透過AWS公佈的一些資料解讀SR-IOV的實現和瓶頸。
從AWS實踐看SR-IOV
AWS從全域性的角度考慮，構建了一套基於Nitro System的方案，實現儲存、網路等多種VF功能，為此，AWS在2015年收購了以3.5億美元收購以色列晶片商Annapurna Labs。
下圖展示了AWS在SR-IOV上的進展，可以看到AWS經歷了從全虛擬化到半虛擬化，而後的2013年到2017年，透過使用SR-IOV技術使得虛擬機器的網路和儲存效能，逐步達到近似Bare-metal performance的水平。
從AWS產品服務來看，2013年的CR1的實現，不論儲存和網路訪問都是要過Amazon的hypervisor layer（Xen）的。
而到了2017年的C5，VM的EBS Storage和Network全部不透過Amazon Linux hypervisor layer，而透過Lightweight Nitro hypervisor。
對於這個Nitro Hypervisior，AWS給出的解釋是這是一個new hypervisor，但是不僅僅是個hypervisor。基於Annapurna Labs這顆晶片，AWS實現了PCIe裝置PV到VF的SR-IOV虛擬化功能，利用Nitro Hypervisior實現了QoS管理功能。看AWS的C5和C5D機型的配置，VF可以是50、100、200、400、900GB的大小。
Memblaze測試工程師申請了一個亞馬遜AWS伺服器以及一個c5d.large的NVMe SSD，從AWS官方看到實體配置可知c5d.large的IOPS讀被限制在2萬IOPS、寫被限制在9000IOPS。
Memblaze申請的AWS伺服器
Amazon EBS 和 NVMe
在基於 Nitro system的虛擬機器上，EBS 捲顯示為 NVMe 塊儲存裝置，這些裝置依賴於作業系統上的標準 NVMe 驅動程式。這些驅動程式通常在虛擬機器啟動期間，透過掃描 PCI 匯流排來發現連線的裝置，然後根據裝置響應的順序建立裝置節點。裝置名稱為：
/dev/nvme0n1、/dev/nvme1n1…
以此類推。
實測，可以看到AWS可同時給雲主機提供EBS（上圖Amazon Elastic Block Store）遠端儲存和本地NVMe SSD（上圖Amazon EC2 NVMe Instance Storage），兩者均被識別為一個PCIe裝置。
分別測試兩者的讀和寫延遲。測試結果如下：
AWS VM的Instance store(nvme1n1)讀latency在96μs
AWS VM的Instance store(nvme1n1)寫latency 99.95%都在24-37μs
透過Nitro 虛擬化後虛擬機器僅增加了10μs延遲。AWS全域性的SR-IOV設計理念在於，儲存和網路都可以透過Nitro系統實現SR-IOV，分散式的EBS捲經Nitro Card到虛擬機器就成為了一個NVMe塊儲存裝置，而不需要底層的SSD支援SR-IOV。
但是全球只有AWS做到了這點，他的SR-IOV實踐證明這項技術價值的同時也展示了其技術實力。
Memblaze在SR-IOV領域的研究現狀
另一方面，SSD實現SR-IOV的同時，需要系統做相應的修改和調優處理，這裡總結了企業客戶實現SR-IOV的幾點需求。
從安全性考慮，NVMe SSD需要實現多名稱空間管理，並且滿足使用名稱空間的租戶之間不能互相訪問到資料，尤其是名稱空間重新分配給雲主機使用者的時候。
從雲主機業務效能QoS保障的角度，需要NVMe SSD實現不同VF之間的I/O隔離。而這裡的I/O隔離同樣需要基於多名稱空間實現。
（關於多名稱空間可以參看文末相關閱讀中的《實錘，PBlaze5實力演繹multiple namespaces 功能》）
PCIe驅動以及NVMe驅動的修改。驅動是連線系統和SSD的關鍵，這裡需要修改PCIe Driver對 VF BAR空間地址的分配機制以及修改NVMe Driver對VF I/O超時處理的機制
最後也是最重要的是合作，SR-IOV實現需要Memblaze與客戶進行環境聯調，以及大規模測試驗證，以此保障SR-IOV功能的可靠性、效能表現等。
