VPC（全稱是Virtual Private Cloud，做網絡的同學尤其注意，不是思科vPC的virtual Port Channel）是AWS的云平臺概念，OpenStack里并沒有這一個內容；比較起來，VPC對應OpenStack的一個vRouter及其相關的網絡和子網等資源。通常來講，Neutron的兩個vRouter是相互隔離的，才能確保尤其是不同租戶之間的安全性，但是在某些場景下存在兩個VPC間互通的需求，這種需求的解決方案在AWS里稱之為VPC-Peering（http://docs.aws.amazon.com/zh_cn/AmazonVPC/latest/PeeringGuide/Welcome.html
），這些場景舉例來說：
1. 災難恢復的場景，需要將VPC的數據同步到另一個VPC，實現容災備份；AWS的VPC現在是不能跨Region的，特定VPC子網也不能跨AZ（Availability Zone），但AWS的VPC-Peering雖不支持跨Region，但支持跨賬戶；
2. 混合云中尤其是不同云平臺的數據間通信時，使用VPC間通信也是可以的，但VPC通信并不是一種標準的通信特性或通信協議，所以會對管理平臺或數據模型有一定匹配度要求；
3. 在云平臺部署到眾多DC規模較小且相互聯接的情況下，通過VPC互通為節省用戶數據通信的成本；
AWS的官網明確說明，“AWS 使用現有 VPC 基礎設施創建 VPC 對等連接，既不是網關，也不是 VPN 連接，因此不依賴某個獨立的實體硬件。沒有單點通信故障也沒有帶寬瓶頸”，并且有如下主要限制（http://docs.aws.amazon.com/zh_cn/AmazonVPC/latest/PeeringGuide/vpc-peering-overview.html#vpc-peering-limitations）：
1）無法在具有匹配或重疊的 CIDR 塊的 VPC 之間創建 VPC 對等連接；
2）無法在位于不同區域中的 VPC 之間創建 VPC 對等連接；
3）只能為每個 VPC 創建數量有限的活動和待定 VPC 對等連接；
4）VPC 對等不支持傳遞的對等關系；
5）不能在相同兩個 VPC 之間同時建立多個 VPC 對等連接；
6）通過 VPC 對等連接的最大傳輸單元 (MTU) 為 1500 字節；
7）不支持在 VPC 對等連接中進行單一地址反向傳輸路徑轉發；
8）置放組可以跨越對等的 VPC；但是，您不會在對等 VPC 中的實例之間獲得完全等分的帶寬；
9）一個實例的公有 DNS 主機名稱不會跨對等的 VPC 解析為其私有 IP 地址。
AWS的VPC-Peering管理模型和建立過程與VPN有類似之處，需要建立一個通信認證機制和通信的狀態管理，這些都是OpenStack控制面所缺少的，AWS的VPC-Peering通信狀態機制如下：
相比于AWS的網絡豐富特性之一，VPC-Peering，除了需要實現建立通信認證機制外，OpenStack的網絡組件Neutron也并沒有明確支持的對象，不過我們可以在現有Neutron能力基礎上， 在此類討論下有哪些可能的實現方案：
1）基于IPSec類似的端到端VPN
如果將兩個vRouter之間建立一條端到端的VPN隧道，實現VPC互通是行的通的，但是這個方案對云平臺的依賴度較高，就是說如果建立VPN隧道是通過公網IP來進行，那么基本可以歸結為VPN功能（這個時候的帶寬和網絡延遲就會有影響），特性也不是VPC-Peering了，所以需要對云平臺內網要求有一個內網網段和vRouter打通，讓租戶感知來創建基于內網的諸如IPSec VPN隧道。另外，還需要考慮到，IPSec自身是不支持組播和廣播的，租戶此類業務需要通過GRE+IPSec的技術租戶來實現。
2）share network
基于OpenStack云平臺的管理員可以使用Neutron來創建Shared類型的Network，這樣基本所有租戶都看的到并創建虛擬機在上面進行通信，比如浮動IP的external-network基本是將Shared屬性設置為True的。那么需要互通的兩個VPC網段的虛擬機可以都多出來一個port連接到Shared network上實現VPC互通。這個Share Network為了防止占用公網地址成本高，可以選擇一個大范圍的私網地址段；這種方式
a）要求這個Shared network必須預先創建，且其網段范圍有特殊要求，盡量減少與租戶VPC網段地址重疊的影響；
b）該Share Network為管理員創建的，所以所有租戶都可以看到并使用，這樣就破壞了VPC的安全隔離性，需要不同VPC之間互通的時候做好安全控制；
3）VM連接跨VPC的network實現VNF
當一個租戶的兩個VPC想互通，可以簡單的啟動一個虛擬機實例，讓該虛擬機同時連接到兩個VPC各對應由互通訴求的網絡上；該方案相比于AWS的VPC-Peering需要指定虛擬機的Fixd IP，并在虛擬機內部加載路由和過濾規則，實現指定網段地址的VPC互通；另外為了實現將某個VPC發往另一個VPC流量到該虛擬機實例進行中轉，需要借助Service chain或者策略路由的方式進行引流，然后讓虛擬機實現VNF(Virtual Network Function)的功能打通VPC通路。
但是該方案若是有需求實現兩個租戶其各自一個VPC之間互通時，因為沒有任何一個租戶可以看到對端的資源，所以就會產生創建虛擬機時連接網絡的權限問題，需要借助管理員創建虛擬機來打通兩個VPC；這無疑為VPC互通時租戶的管理和維護帶來不方便。
4）借助Gre/Vxlan等隧道模式
最后說一種業界比較常用的方案，就是在兩個vRouter之間建立一條Gre或Vxlan的內網新隧道，該方案原理上與Share Network類似，都是使用一個新的隔離域，但是僅是兩個VPC間私有，不為其他VPC共享。該方案中的Gre或Vxlan隧道隔離域值可以是Neutron從預，留的范圍里面進行分配，然后借助SDN控制器打通整條鏈路的通道，從而實現兩個VPC間的互通，猜測AWS的VPC-Peering的實現是基于此方案。但是該方案需要針對Neutron進行特定的開發，而且使用成本也相對較高，當然所能使用的帶寬和延遲等性能指標，也會較好。
當然，當Neutron的租戶網絡使用Vxlan時，VPC間通信使用另一種隔離方式比如Gre思路會比較清晰，但是數據轉發面實現和運維相對會增加復雜度。
總之，基于Neutron的VPC間通信方案還沒有社區的統一實現，各種方案成本、可靠性、性能、隔離性和可維護性等不太相同，需要根據自己的業務實際情況和技術積累，選擇合理低成本的方案。
作者簡介：李俊武，sina微博北京-小武，著有《云計算網絡珠璣》；三年多交換機研發經歷（熟悉Broadcom、Marvell等公司交換芯片轉發流程和網絡協議），兩年多基于Openstack云計算平臺架構設計經驗，現在華為IT產品線的云計算網絡架構與設計組，參與華為公有云和私有云的架構設計方面的工作，包括云平臺網絡集成華為SDN控制器方面的設計工作等。
京公網安備 11010502049343號