深入浅出新一代云网络——VPC中的那些功能与基于OpenStack Neutron的实现（三）-路由与隧道

0755mx

　　在系列的上一篇，
　　深入浅出新一代云网络--VPC中的那些功能与基于OpenStack Neutron的实现（二） ，
　　http://www.cnblogs.com/opsec/p/6895746.html
　　主要讲了在多租户场景下一个重要的网络功能——带宽QOS的原理与实现。
　　先同样给出一份 aio风格的 REST API 示例代码，同样可以在不修改Neutron代码的情况下独立使用。
　　opencloudshare/Op_vmqos
　　https://github.com/opencloudshare/Op_vmqos
　　逻辑原理在上一篇中介绍的比较详细，主要就是通过 OpenStack API 找到云主机的虚拟NIC设备所在的宿主机，通过paramiko到宿主机上执行写入TC规则。
　　使用的话可以灵活的修改 region、domain等参数，代码里使用的默认的。
　　找到虚拟NIC设备也不一定通过VM id的方式，可以根据需要修改。比如，在之前的一个项目中，涉及到了 “根据当前网络流量自动扩容带宽” 功能，简单来说是 “当前云资产带宽使用率达到X时，自动通过控制器对云资产所享有的带宽进行扩容”。当时的环境没有Ceilometer ，使用的方案是 在宿主机上装了 Zabbix agent，对所有网卡实现自动发现，然后监控并在触发阈值后，传值调用 QOS的REST API，当时传的值，就是具体的 NIC设备名，而不是 VM id。
　　实现三层共享带宽与控制原理是相同的，只是提取L3 namespace里的NIC设备名时，为 router-port 相关方法。
　　进入今天的正题——路由、隧道与案例，在实际的云计算场景中，混合云占了很大一部分，一般我们对混合云的概念定义，是指既有私有云的内容，又结合了在公有云上的部分，共同建设、组成的云环境。

经典案例，是在各大峰会上被经常拿来说的 新浪微博混合云架构实践。既包含了业务层面 网络、存储、Docker 等领域的挑战，也存在 控制层面的 运维管理、弹性调度等的考量。

　　上面说的“私有云内容”，其实可以扩充为 “任何私有IT环境” 。各位云计算工程师们一定遇到过很多 在“云” 的概念提出以前的IT建设项目 与 新的云计算环境打通接入 的需求。就好像私有云项目中客户经常会要求能和以前的IT设施互访，而不是简单的部署一个割裂的环境或迁移。直接使用VLAN技术将租户网络接入外部网络可能并不是一个通用性的选择，因为与VXLAN二层+VPC网络相比，前者有更多的侵入性、需要更复杂的网关层面的路由控制等。NAT技术则是将网络连接的层次提高了一层，用户有明确的感知，在云资产数量较多及全端口的需求下，对NAT规则的控制与上层网络可使用的IP数量成了瓶颈。因而隧道技术成了更好的选择。
　　接下来我将以几个参与的case为例，讲讲在面对复杂的互联互通需求时，可以考虑的方案，与利用 OpenStack Neutron 完成的功能。

• case 1
  

客户已有一套传统IT环境，现要求与新部署的OpenStack环境某一VPC内云资产进行互访。

　　OpenStack 的 neutron-vpn-agent 可以提供 IPsec VPN服务，在路由间建立隧道。
　　在企业内网环境，还可以使用配置更方便的 GRE隧道和IPIP隧道。
当然，具体使用何种协议，更多的是看路由设施对协议的支持程度，l3-agent 在 namespace建立的软路由因为基于linux kernel ，在没有极高性能要求的场景下可以支撑种类繁多的协议。而当对端是物理设备时，则得确定是否支持。
　　IPsec VPN就不做示例了，官方文档即可查看。
　　软实现GRE隧道打通的简单示例：





# 加载模块
modprobe ip_gre
# 建立隧道，隧道名，隧道类型，远端地址，本地地址
ip tunnel add mytunnel mode gre remmote 10.200.11.22 local 10.100.1.11
# 设置隧道接口地址，任一不和待打通的网络冲突的即可
ifconfig mytunnel 10.199.199.1 netmask 255.255.255.0
# 添加到对端网络的路由
ip route add 192.168.3.0/24 dev mytunnel
　　在对端：





# 加载模块
modprobe ip_gre
# 建立隧道，隧道名，隧道类型，远端地址，本地地址
ip tunnel add mytunnel mode gre remmote 10.100.1.11 local 10.200.11.22
# 设置隧道接口地址，任一不和待打通的网络冲突的即可
ifconfig mytunnel 10.199.199.2 netmask 255.255.255.0
# 添加到对端网络的路由
ip route add 192.168.1.0/24 dev mytunnel
　　之后，便可测试OpenStack VPC内的这个网络到右侧已有网络的打通互访效果。

• case 2
  

客户已有一套传统IT环境，现要求与新部署的OpenStack环境内 多个 VPC内云资产进行互访。

　　这个case是上一个的加强版。如果是在OpenStack环境内的网络打通，同一project下，我们会将多个网络连接同一路由，如果接口不是默认网关，添加对应的路由表。
　　在这个案例中，传统IT环境与OpenStack环境的外部网络其实是通过物理专线相连接的，而OpenStack内多个VPC的使用者是企业的不同项目组。简而言之，这多个项目组，要求共用同一条物理专线，但都能访问到各自的VPC内。

　　在各VPC原有路由不变(默认网关为 x.x.x.1)的情况下，建立一个专用路由，将各VPC内各网络接入该专用路由(专线网关为 x.x.x.99)，用该路由通过物理专线与传统环境形成打通。
　　软实现IPIP隧道打通的简单示例：





# 加载模块
modprobe ipip
# 建立隧道，隧道名，隧道类型，远端地址，本地地址
ip tunnel add mytunnel mode ipip remmote 10.200.11.22 local 10.100.1.11
# 设置隧道接口地址，任一不和待打通的网络冲突的即可
ifconfig mytunnel 10.199.199.1 netmask 255.255.255.0
# 添加到对端网络的路由
ip route add 192.168.3.0/24 dev mytunnel
　　在对端：





# 加载模块
modprobe ipip
# 建立隧道，隧道名，隧道类型，远端地址，本地地址
ip tunnel add mytunnel mode ipip remmote 10.100.1.11 local 10.200.11.22
# 设置隧道接口地址，任一不和待打通的网络冲突的即可
ifconfig mytunnel 10.199.199.2 netmask 255.255.255.0
# 添加到对端网络的路由
ip route add 192.168.1.0/24 dev mytunnel
ip route add 192.168.2.0/24 dev mytunnel
ip route add 192.168.0.0/24 dev mytunnel
　　还没有完，因为对VPC内的云资产来说，默认网关是 x.x.x.1 ，意味着在不改动云资产内路由表的情况下，发往 192.168.3.0/24 的数据包都将发往 x.x.x.1 。所以我们需要对三个VPC的路由设施添加路由表，将数据包转发至 x.x.x.99 。





vpc1_routes: {"destination": "192.168.3.0/24", "nexthop": "192.168.1.99"}
vpc2_routes: {"destination": "192.168.3.0/24", "nexthop": "192.168.2.99"}
vpc3_routes: {"destination": "192.168.3.0/24", "nexthop": "192.168.0.99"}
　　由传统环境到云上多个VPC的互访功能即可实现，且 VPC 与VPC 间仍是不能互访的。
　　在这个 case 中，我更推荐将用于专线的路由不使用默认的L3-agent —— neutron api 中的router 去创建，而是以云主机的形式建立，理由如下：

• 原router所有的内部接口现在是云主机的各NIC，可以通过对云主机的控制来改变配置，避免了直接操作L3节点可能的风险；
  
• 可以在云主机而非L3节点内装 满足复杂网络监控需求的软件/Agent；
  
• 通过调整CPU来调整转发能力；
  
• 通过控制port 来控制各VPC对专线带宽的占用情况与应急断连的保护；
  
• 云主机可以主备，在自动切换、恢复与迁移方面更方便。
  

　　在OpenStack环境建立用于转发功能的云主机，除了将 云主机操作系统内核参数的 ip_forward打开外，还需通过Neutron 对该云主机的port 进行 port_security_enabled = False 的操作。这一点在部署云主机版的NAT网关时同样适用。

• case 3
  

客户要求将一台高性能物理机接入云上VPC内，方便资源的互访。

　　走南北方向的其它区域，是最简单的方案。

但难点在于，客户并不想暴露OpenStack环境所在区域南北方向上的其它IP地址。换而言之，想让VPC内租户通过VPC内网络的地址访问到物理机。NAT是个不错的选择，基于前两个case的路由隧道方案也可以不必暴露基础环境中南北方向的IP规划。

　　

　　
但我们也可以利用 OVS 的特性，将以有这个需求的VPC内网络用 VLAN 组网，实现基于物理 VLAN 交换机的跨物理服务器二层虚拟网络 ；或是 仍用 VXLAN 组网，但使用支持 VXLAN 的物理交换机来扩展原本架构。
　　我们知道， VTEP 和 VXLAN GW 是VXLAN组网在东西向扩展的核心组件，混合Overlay 方案通过结合软硬实现VTEP等组件的功能， 同时对虚拟化环境与物理机提供了很好的支持。
　　

　　不过这当然需要物理硬件的支撑。如果在宿主机上安装openvswitch 等软实现，不可避免的会在物理机shell暴露东西向VXLAN GW，肯定是在考虑之外的。


　　关于Neutron VXLAN的内容可以参考云极星创（现海航云）CTO 刘大神写得非常详细的系列：
　　
Neutron 理解 (1): Neutron 所实现的虚拟化网络 [How Netruon Virtualizes Network]
　　http://www.cnblogs.com/sammyliu/p/4622563.html
　　在有其它SDN控制器的场景下，通过Neutron 加载不同 driver 实现对控制器的调度，也能达到效果。
　　之前在和 VMware NSX做技术交流的时候，NSX在对同样需求时给出的参考建议也是通过NSX直接控制 用于物理机接入的交换机。
　　在公有云上，云资产向VPC的引入更常见的方法是通过私有DNS解析与NAT技术相结合的方式，这方面就不展开多谈了，结合前面的文章可以思考他们的大致实现。
　　企业内网与专线环境下，对互联互通功能实现的选择可以使用payload更小，性能更好的隧道技术。但在公网环境下，基于IPSec与SSL的隧道技术从传输安全的角度上是必须考虑的。