Nicholas's Note

[SIGCOMM 2020] MasQ: RDMA for Virtual Private Cloud

  • 2020年 10月23日

Abstract

  • 在VPC中實現RDMA communication目前而言還是個充滿挑戰的工作，因為要兼顧performance跟達成所有virtualization的需求並不容易
  • 這篇論文提供了一個software-defined的解法叫MasQ
  • 核心觀點就是：既然所有RDMA connection跟QP脫離不了關係，那只要好好的定義QP的behavior，應該就能滿足virtualization的需求
  • MasQ利用了virtio-based半虛擬化技術來實作control path，並將data path的部分留給hardware自己handle以避免造成不必要的overhead

1 Introduction

  • 目前大部分的public cloud在提供RDMA network給instance時都會另外弄一個resource pool，造成額外的資金支出
  • 目前virtual switch被用來isolate VPC network，但這方法不能用在RDMA，因為目前的RDMA network interface controller (RNIC)會bypass virtual switch
  • 不論是採用hardware solution或software solution都無法同時兼顧high performance和high scalability
  • hardware solution
    • 核心概念是將network virtualization operation放進2個有開啟single root input/output virtualization (SR-IOV)的RNIC
    • 通常來講，這方法擁有較好的performance但缺少scalability
  • software solution
    • 核心概念是將RDMA control path或加上data path redirect到software component
    • 通常來講，這方法擁有較好的scalability但會降低performance
  • MasQ是將每個RDMA communication關連到1個QP，然後QP context (QPC)負責維護所有send或receive message所必需的資訊，這樣一來如果QPC能夠很好地被虛擬化，則整個RDMA network應該也能做到虛擬化
    • 要做到這件事，首先會將Verbs分成兩大類
      • 操作QPC的Verbs (如”create_qp”)被歸類為control path Verbs
      • 使用QPC的Verbs (如”post_send”)被歸類為data path Verbs
    • 然後只針對control path Verbs虛擬化來減少overhead
  • 要想達成以上目標必須克服2大問題
    • RNIC是會繞過OS kernel的，但virtual switch通常run在kernel上，所以virtual L2 RDMA network不能依賴Virtual eXtensible LAN (VXLAN)或virtual switch來達成network virtualization
    • 由於security group跟firewall as a service (FWaaS)通常運行在virtual switch上，跟上述問題一樣也會被RNIC繞過
  • RDMA I/O virtualization
    • 目前主要有2種技術：direct device assignment以及paravirtualization
      • Direct device assignment：如SR-IOV，可以提供接近原生的效能，但不具彈性
      • Paravirtualization：如VMware的vRDMA技術，paravirtualized的network stack將device driver分成frontend跟backend 2部分，每次做I/O都需要由frontend driver forward到backend driver再forward到physical device。這樣雖具備了彈性但損失許多效能
    • 為了解決上述問題，出現了hybrid virtualization的技術，像是HyV跟virtio-RDMA。HyV在control path即採用paravirtualization，但在data path達成zero-copy
    • MasQ也是採用類似的hybrid技術，但不只著重在I/O虛擬化，更著重在整個VPC裡面啟用RDMA所要面臨的挑戰，如network isolation和apply security rule
  • RDMA network virtualization
    • 介紹FreeFlow跟微軟的AccelNet，提到AccelNet雖能達成團隊所有需求，但需要特殊的硬體才能支援
  • Other works using RDMA in clouds

3 Proposed MasQ

3.1 Rationale

  • 分成三階段
    • 第一階段：Setup phase
      • 對多數的application來說，在這階段的Verbs通通只需操作一次
      • 舉例來說，當QP被建立之後，它將能夠持續地傳送和接收messages，直到它被銷毀
    • 第二階段：Data exchange phase
      • 在這階段的操作必須一直重複直到所有data成功exchange完畢
    • 第三階段：Cleanup phase
      • 以上兩階段完成後，進入該階段釋放所有占用的resources
  • 可以觀察到第一階段與第三階段都是在操作QPC跟resources，而第二階段才是實際在操作data communication
    • 所以第一階段跟第三階段歸類為control path Verbs而第二階段則歸類為data path Verbs
    • 另外，control path Verbs通常只需操作一次，所以對性能不會有太大的影響
  • 以下為將各Verbs進行虛擬化之後所需時間的實驗
    • Host-RDMA是該Verb的原始所需時間
    • w/ virtio則是使用virtio技術虛擬化後所需時間
    • 另外，使用virtio技術時VM到host間communication的平均latency(約20μs)不算在slowdown裡
    • 可以觀察到除去data path Verbs的話，則overhead只有大概9%
    • 大部分會用到RDMA的application通常都會maintain long-lived的連線，再加上control path Verbs通常只需操作一次，只要連線沒斷就不用重作，所以overhead只有one-time cost
    • 大部分會用到RDMA的application通常一跑就是10幾分鐘乃至好幾天，所以幾μs的overhead可以忽略不計
    • 綜上所述，團隊認為這overhead是acceptable的

3.2 I/O Virtualization

  • MasQ’s I/O virtualization架構圖
    • 圖中虛線為data path，實線為control path
  • MasQ採用hybrid的I/O virtualization，如上圖所示，control path使用virtio技術進行虛擬化，而data path則是directly memory mapped，如此一來跟data path有關的資源就可以直接被RNIC或VM中的application access
  • 通常RDMA的data path會有下述2種資源
    • hardware register：如Doorbell，通常hardware register會map到VM裡的physical address，讓application可透過memory-mapped I/O (MMIO)去access
    • VM中的user memory：如QP和user-registered memory regions (MRs)，這些memory可透過guest的virtual address (GVA)跟host的physical address (HPA)做mapping後讓RNIC可以直接access VM裡的user memory
  • 事實上這技術HyV跟virtio-RDMA都有用，所以就不詳述了，更多info放在論文的Appendix A

3.3 Network Virtualization

  • MasQ’s control path架構圖
    • 綠色的元件是目前構思出拿來解決network virtulization問題的

3.3.1 Tenant Isolation

  • MasQ有別於傳統的per-packet virtualization，改採了per-connection virtualization的技術，並命名為RConnrename
  • 其核心理念是讓”tenant (VM中的application)透過virtual network address、cloud provider (MasQ’s backend driver)透過相應的physical network address” (different name)來refer to same connection，這樣當connection建立後，所有封包可以直接被RNIC用physical network address封裝
  • 這技術應用在RDMA領域上可能會有一些挑戰
    • VM可能會有複數個virtual RNIC但application可能只會指定一個virtual destination IP然後就開始進行通訊了，如此一來，MasQ就必須幫忙決定該使用哪個local virtual RNIC
      • 對physical RoCE network來說，這通常不是問題，因為Ethernet跟RDMA interface是在同個PCIe裝置上的，drivers大可透過routing table決定要使用哪個Ethernet interface然後直接使用同個PCIe裝置上的RDMA interface
      • 但是，virtual interface是從不同的virtio device抽象化的，這就必須實作出一個bond來區隔virtual interfaces，於是vBond就被設計出來了
      • 由於RConnrename的運作會依賴vBond，所以以下先介紹vBond
  • vBond是設計來讓VM中的application在僅指定1個IP的狀況下使用2個virtual interfaces (就如同application在access physical RoCE device一樣)
    • 為了達成這件事，vBond被設計成能夠動態bind virtual Ethernet和virtual RDMA interface
      • 在initialization階段，透過query MasQ’s backend driver，vBond會先獲取virtual RDMA interface應綁定到的virtual Ethernet的virtual MAC address
      • 如果virtual Ethernet interface被分配到了合法的IP，vBond會立即初始化global identifier (GID)，並將相應的virtual RDMA interface與該virtual Ethernet interface bind在一起
      • 接著，vBond會去OS中將callback function註冊到inetaddr event的notification chain，之後如果virtual Ethernet interface的IP有變，OS就會通知vBond去檢查並更新GID (GID在RDMA network中是拿來辨識RDMA interface的)
  • RConnrename是用來保證封裝RDMA封包時使用正確的network address，避免RNIC使用virtual IP/MAC address作為destination address
    • 為避免RNIC使用virtual IP/MAC address作為destination address，必須保證application發出的command都要被預處理過
    • 根據上面的MasQ’s control path架構圖，我們可以發現application發出的command在送到real device driver之前都會先送到MasQ’s backend driver
    • MasQ可以利用這個機會讓application看到的QPC是virtual network address，而RNIC看到的QPC是physical network address
  • Example
    • (1)表示不管client還是server都必須經過control path創建QP並註冊他們的memory regions，”create_qp”這個command和QP的address mapping (GVA, GPA)會被forward到host
    • backend driver收到command後會再把GVA map到HPA，並呼叫device driver創建QPC (QPC在host端維護)
    • 一旦local resource準備好了，application就可以去query它的local GID
    • 由於vBond紀錄了virtual GID，所以可以直接回覆該query request，如(2)
    • 拿到local connection information (如QP number、virtual GID)後，application必須將這些資訊交換給另一個peer，這通常會經由一個預先建立好的TCP connection，如(3)
    • 有了peer’s connection information，application就必須設定自己的QPC將destination network address設為另一端的vGID
    • 之後到RConnrename，RConnrename必須將vGID轉換為pGID，但是前面提到的vBond在initialize GID時並沒有pGID (畢竟它位於guest內)
    • 討論如何拿pGID之前還必須先解決另一個問題，那就是不同的tenant的virtual IP address可能會是一樣的，這意味著整個cloud裡可能會有許多相同的vGID，這樣就不能只把vGID當作key來找pGID，解決方法是把tenant的ID也拿進來當key
    • 有了vGID跟tenant ID，RConnrename就可以去一台專門存vGID跟pGID對應關係的centralized remote controller做query，如(4)
    • 另外，當vGID有變或是剛被創建時，vBond需要馬上notify controller去更新

3.3.2 Sercurity Isolation

  • RDMA security in VPC大致能分為network security和user memory security
    • 違反network security rules的流量不應該進入network中
    • user memory (如QPs或MRs)不應被未授權用戶access
  • Network security
    • 使用2 level security mechanism，network level使用FWaaS，VM level使用security group
    • 一般來說，security rules由INPUT、OUTPUT、FORWARD三種rules組成，且三種rules分別以chain的形式存在
      • 實現方法通常為接收到封包時，會去每個chain檢查是否有符合的rule (這些rule通常從priority高排至低)，若有則採取定義好的action，若都沒有match到rule，則預設會drop掉封包
      • 這方法常見於hypervisor中的virtual bridge跟virtual switch
      • 但是，由於virtual RDMA的data path繞過了hypervisor，便無法透過上述方式實現封包攔截
      • 為了解決傳統scan policy rule無法過濾RDMA封包的問題，團隊利用了security rules的一種feature：”connection tracking”
      • connection tracking原本是用來解決”每個封包都要scan一次policy rules很花時間”這件事，將其改成”已成功被建立的connection (成功通過security rule檢查並被放行)所屬的封包不需要被檢查”
      • 如此一來要在virtual RDMA network應用security rule可以被簡化成3個小問題
        • 在沒有通過security rule的狀況下所有RDMA connection是不可被建立的
        • 所有RDMA封包都是不被允許的，除非該封包隸屬於某個已被建立的RDMA connection底下
        • 只要rule被更新，所有因更新而不被允許的connection需盡快被block
      • 上述3個問題中前2個非常容易解決，因為MasQ’s backend可以幫忙deny違反rule的request，且RNIC也不會在未建立RDMA connection的狀況下傳送RDMA訊息。另外，由於connection的建立一定會經過virtual Ethernet interface，但virtual Ethernet interface是不能繞過hypervisor的所以能受firewall及security rule限制
      • 為了解決第3個問題，MasQ另外設計了一個位於backend的元件叫做RConntrack
        • 它無法像TCP/IP network一樣直接drop掉封包
        • 由於control path是半虛擬化的，QP的state是可以由host來控制的，透過modify QP state為ERROR來讓RNIC立即停止處理data
        • 下圖為QP的state machine，紅色虛線顯示出QP可以從任何state切換到ERROR
        • 下圖為QP的state切換到ERROR時，application跟RNIC的行為
        • Example
          • (1)是正常的connection，成功建立後RConntrack會將tuple (<Tenant ID:192.168.1.1, 192.168.2.1>)存進connection table
          • 當rule改變，跨subnet被視為invalid時，新的connection request會像(2)一樣在RConntrack被攔下，RConntrack也會檢查connection table中是否有不合法的連線，若有則將QP state改為ERROR
  • User memory security
    • RDMA resources如QP、MR和protection domain (PD)由MasQ backend driver建立，如此一來任一VM就不能操作其他VM的資源
    • 要想跟remote QP溝通，connection必須建立在reliable connection mode之上，或是建立在unreliable datagram mode上並提供Q-Key，如此一來illegal request可以很容易被辨識出來並拒絕掉
    • 要想存取remote MR，必須提供memory key，且remote QP跟MR必須屬於同個PD
    • 任何memory operation都必須跟RDMA中的QP關聯
    • RNIC必須檢查每個RDMA operation的MR的boundary，這樣access memory時才不會access到合法範圍外的MR

3.3.3 Quality of Service

  • 為避免QoS operation (如rate limiting)對效能造成多餘的影響，MasQ盡量採用hardware-based的方法
  • 像上述提到的rate limiting，MasQ透過把QP mapping到不同的hardware-based rate limiter來提供QP-level的QoS
  • 另外，為了提供hardware resource更好的scalability，MasQ提供了QP grouping讓QP之間可以透過特定的rule組成一個group再map到rate limiter
    • 例如grouping QPs by tenant再map到rate limiter，這樣可提供per tenant的QoS，也能在tenant數量少於rate limiter時保證各tenant的QoS
  • 目前MasQ利用SR-IOV VF來實做QoS，因為其對商用RNIC支援度高且每個VF設定QoS的方法也都被大量研究過了
  • 但是團隊並非直接將VF pass給VM而是讓MasQ backend driver來決定要由哪個VF來serve來自不同的tenant、application、VM的request

3.3.4 Connectionless transport

  • 雖說這篇論文主要著重在connection-based transport，像是reliable connection mode但要知道reliable connection mode RDMA會面臨scalability問題，所以支援datagram-based RDMA也很重要
  • 每個RDMA datagram message都會用work queue element (WQE)夾帶network information，所以我們可以讓user把datagram WQE forward給control path，這樣一來RConnrename就能在forward WQE給real device driver前將virtual network information替換成physical的
  • 收到WQE後RNIC就能用DMA直接在application’s user space寫message data
搜索