+86 135 410 16684Mon. - Fri. 10:00-22:00

Neutron实现AWS VPC-Peering

Neutron实现AWS VPC-Peering

Neutron实现AWS VPC-Peering

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通信状态机制如下:
wp-content%2Fuploads%2F2016%2F06%2FNeutron-AWS-vpc-figure-1
相比于AWS的网络丰富特性之一,VPC-Peering,除了需要实现建立通信认证机制外,OpenStack的网络组件Neutron也并没有明确支持的对象,不过我们可以在现有Neutron能力基础上, 在此类讨论下有哪些可能的实现方案:

1)基于IPSec类似的端到端VPN
wp-content%2Fuploads%2F2016%2F06%2FNeutron-AWS-vpc-figure-2

如果将两个vRouter之间建立一条端到端的VPN隧道,实现VPC互通是行的通的,但是这个方案对云平台的依赖度较高,就是说如果建立VPN隧 道是通过公网IP来进行,那么基本可以归结为VPN功能(这个时候的带宽和网络延迟就会有影响),特性也不是VPC-Peering了,所以需要对云平台 内网要求有一个内网网段和vRouter打通,让租户感知来创建基于内网的诸如IPSec VPN隧道。另外,还需要考虑到,IPSec自身是不支持组播和广播的,租户此类业务需要通过GRE+IPSec的技术租户来实现。

2)share network
wp-content%2Fuploads%2F2016%2F06%2FNeutron-AWS-vpc-figure-3
基于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
wp-content%2Fuploads%2F2016%2F06%2FNeutron-AWS-vpc-figure-4
当一个租户的两个VPC想互通,可以简单的启动一个虚拟机实例,让该虚拟机同时连接到两个VPC各对应由互通诉求的网络上;该方案相比于AWS的VPC- Peering需要指定虚拟机的Fixd IP,并在虚拟机内部加载路由和过滤规则,实现指定网段地址的VPC互通;另外为了实现将某个VPC发往另一个VPC流量到该虚拟机实例进行中转,需要借 助Service chain或者策略路由的方式进行引流,然后让虚拟机实现VNF(Virtual Network Function)的功能打通VPC通路。

但是该方案若是有需求实现两个租户其各自一个VPC之间互通时,因为没有任何一个租户可以看到对端的资源,所以就会产生创建虚拟机时连接网络的权限问题,需要借助管理员创建虚拟机来打通两个VPC;这无疑为VPC互通时租户的管理和维护带来不方便。

4)借助Gre/Vxlan等隧道模式
wp-content%2Fuploads%2F2016%2F06%2FNeutron-AWS-vpc-figure-5
最后说一种业界比较常用的方案,就是在两个vRouter之间建立一条Gre或Vxlan的内网新隧道,该方案原理上与Share Network类似,都是使用一个新的隔离域,但是仅是两个VPC间私有,不为其他VPC共享。该方案中的Gre或Vxlan隧道隔离域值可以是 Neutron从预留的范围里面进行分配,然后借助SDN控制器打通整条链路的通道,从而实现两个VPC间的互通,猜测AWS的VPC-Peering的 实现是基于此方案。但是该方案需要针对Neutron进行特定的开发,而且使用成本也相对较高,当然所能使用的带宽和延迟等性能指标,也会较好。

当然,当Neutron的租户网络使用Vxlan时,VPC间通信使用另一种隔离方式比如Gre思路会比较清晰,但是数据转发面实现和运维相对会增加复杂度。

总之,基于Neutron的VPC间通信方案还没有社区的统一实现,各种方案成本、可靠性、性能、隔离性和可维护性等不太相同,需要根据自己的业务实际情况和技术积累,选择合理低成本的方案。