澳门新葡新京网址美团云入选Top100年度技术创新案例

美团云入选Top100年度技术创新案例

• 作者 庞杰 •
2015年12月10日17:34 • 速途网

  Top100summit是科技界一年一度的案例研究峰会,每年甄选有学习价值的100个技术创新或研发管理实践,分享本年度最值得总结、盘点的实践启示。12月5-7日,Top100summit案例研究峰会在北京国家会议中心隆重举办。美团云作为领先的O2O电商云和大数据解决方案提供商,入选TOP100年度技术创新案例。美团网高级技术专家王昕溥在大会上发表了以《软硬结合,新旧并举》为主题的演讲,揭秘美团云网络演化进程。

  王昕溥讲到,似乎提到美团大家联想到的只是团购,但美团早已不是单纯的团购,更有猫眼电影、机票、酒店、外卖等丰富的业务。同时,总有人会问美团为什么要做云?做好电商才是美团该走的路。实则不然。电商拥有的大数据是天然做云优势,数据在高峰期的波动也使得电商在资源弹性调度方面有一定的积累。而美团早已在2012年开始逐步创建自己的云平台,2013年5对正式对外推出公有云服务。同年7月,美团所有业务迁移至美团云平台上。至今,美团云已创建多年,在大数据分析服务上有了很深的积累,希望将此经验分享给大家。

  

澳门新葡新京网址 1

  美团云没有完全选用OpenStack,而是决定基于OpenStack自研云平台。原因在于当时OpenStack并不成熟,例如需要软件网关在VM上,网络模式配置比较死板,无法满足美团业务的需求。现在看来,因祸得福。由于OpenStack偏向私有云,如果当初完全基于OpenStack,现在做公有云将比较困难。但美团云选择自研云平台,结合自身业务,在OpenStack的基础上不断加入自研的策略,现如今平稳地支撑着所有业务。

  美团私有云研发目标除自研外还包括:资源云化和减少性能损耗。这需要做到快速交付、灵活地调整以及对访问控制和资源隔离不做太多要求。办公云的目标是动态地开发测试资源、从计费系统和公有云的预发环境入手试水公有云。而早期公有云的目标在于:纯软解决方案,底层采用VLAN,通过OVS控制器对用户进行隔离;因为当时仅为千兆网络,因此对软件性能要求不高。由此可预想到早期公有云存在着诸多问题。首先,内外网单连线,任何地方不稳定都将导致重大问题,若为三根网线,成本则太高;交换机对VLAN的支持能力限制了网络规模的扩展,用户数量受到限制;软件隔离占用宿主机计算资源;无法实现用户自定义网络,灵活性低。

  经过不断地改进,现美团新公有云网络架构得到全面升级。

  首先,从物理链路来看,实现万兆互联、双机冗余,管理网做粘接,用户的内外网全部覆盖在管理网上。通过VLAN隔离用户,可自定义网络,灵活性大大提高。并且,拥有浮动IP、负载均衡、对象存储、块存储、RDS、Redis等丰富的产品。具体来看,采用10G
Base-T电口万兆网络。而网络一分为二:overlay网络和underlay网络。这意味着不再受限于物理上的连接和端口数量,可以按照资源池的概念来分配网络资源。而Underlay网络作为整个SDN框架的基础,充分吸取和延续了过去长期积累的物理网络优势。同时,核心机柜封闭冷通道,此举大大降低了成本,同时方便了运维。

  其次,网关、主机网络、控制3方面性能释放。浮动IP网关、负载均衡网关、DDos清洗设备等全面DPDK化,64字节小包20G线速,并发1000w链接情况下新建连接100w/s。主机上又是如何充分释放万兆互联呢?在曾经V1.1版本上千兆仍可行,但万兆不行。升级到V2.3后平台创建能够满足要求,但利用率仅为20-30%。而升级到V2.4V,支持DPDK,进一步提升单流转发性能。控制上早期选择有iptables,主要选用OVS控制器对数据包进行过滤和处理。但存在需要配置或更新大量规则和难以实现更灵活控制的问题。后通过VXLAN对用户进行隔离、VNI内数据包不隔离、OFFLOAD
VXLAN的封装解封装到交换机上。

  目前,美团云更多地采用自动化运维,将过去长期通过debug或diag等手段去查看改为,通过openflow或者netconf等通信手段提取到控制器上,进一步整理和分析。未来,美团云将在此基础上不断进行架构升级与技术创新,软硬结合,新旧并举,大幅提高运维效率,为用户提供更优质的公有云服务。

# 加载模块
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

主要讲了在多租户场景下一个重要的网络功能——带宽QOS的原理与实现。

在这个案例中,传统IT环境与OpenStack环境的外部网络其实是通过物理专线相连接的,而OpenStack内多个VPC的使用者是企业的不同项目组。简而言之,这多个项目组,要求共用同一条物理专线,但都能访问到各自的VPC内。

先同样给出一份 aio风格的 REST API
示例代码,同样可以在不修改Neutron代码的情况下独立使用。

澳门新葡新京网址 ,进入今天的正题——路由、隧道与案例,在实际的云计算场景中,混合云占了很大一部分,一般我们对混合云的概念定义,是指既有私有云的内容,又结合了在公有云上的部分,共同建设、组成的云环境。

接下来我将以几个参与的case为例,讲讲在面对复杂的互联互通需求时,可以考虑的方案,与利用
OpenStack Neutron 完成的功能。

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

OpenStack 的 neutron-vpn-agent 可以提供 IPsec
VPN服务,在路由间建立隧道。

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

在公有云上,云资产向VPC的引入更常见的方法是通过私有DNS解析与NAT技术相结合的方式,这方面就不展开多谈了,结合前面的文章可以思考他们的大致实现。

在企业内网环境,还可以使用配置更方便的 GRE隧道和IPIP隧道。
当然,具体使用何种协议,更多的是看路由设施对协议的支持程度,l3-agent 在
namespace建立的软路由因为基于linux kernel
,在没有极高性能要求的场景下可以支撑种类繁多的协议。而当对端是物理设备时,则得确定是否支持。

在各VPC原有路由不变(默认网关为
x.x.x.1)的情况下,建立一个专用路由,将各VPC内各网络接入该专用路由(专线网关为
x.x.x.99),用该路由通过物理专线与传统环境形成打通。

澳门新葡新京网址 3

深入浅出新一代云网络–VPC中的那些功能与基于OpenStack
Neutron的实现(二) ,

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

由传统环境到云上多个VPC的互访功能即可实现,且 VPC 与VPC
间仍是不能互访的。

# 加载模块
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
  1. 原router所有的内部接口现在是云主机的各NIC,可以通过对云主机的控制来改变配置,避免了直接操作L3节点可能的风险;
  2. 可以在云主机而非L3节点内装 满足复杂网络监控需求的软件/Agent;
  3. 通过调整CPU来调整转发能力;
  4. 通过控制port 来控制各VPC对专线带宽的占用情况与应急断连的保护;
  5. 云主机可以主备,在自动切换、恢复与迁移方面更方便。

我们知道, VTEP 和 VXLAN GW
是VXLAN组网在东西向扩展的核心组件,混合Overlay
方案通过结合软硬实现VTEP等组件的功能,
同时对虚拟化环境与物理机提供了很好的支持。

实现三层共享带宽与控制原理是相同的,只是提取L3
namespace里的NIC设备名时,为 router-port 相关方法。

  • case 1

 

之前在和 VMware
NSX做技术交流的时候,NSX在对同样需求时给出的参考建议也是通过NSX直接控制
用于物理机接入的交换机。

关于Neutron VXLAN的内容可以参考云极星创(现海航云)CTO
刘大神写得非常详细的系列:

这个case是上一个的加强版。如果是在OpenStack环境内的网络打通,同一project下,我们会将多个网络连接同一路由,如果接口不是默认网关,添加对应的路由表。

在对端:

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

澳门新葡新京网址 4

在这个 case 中,我更推荐将用于专线的路由不使用默认的L3-agent —— neutron
api 中的router 去创建,而是以云主机的形式建立,理由如下:

  • case 3

Neutron 理解 (1): Neutron 所实现的虚拟化网络 [How Netruon Virtualizes
Network]

 

企业内网与专线环境下,对互联互通功能实现的选择可以使用payload更小,性能更好的隧道技术。但在公网环境下,基于IPSec与SSL的隧道技术从传输安全的角度上是必须考虑的。

使用的话可以灵活的修改 region、domain等参数,代码里使用的默认的。

opencloudshare/Op_vmqos

IPsec VPN就不做示例了,官方文档即可查看。

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"}

 

找到虚拟NIC设备也不一定通过VM
id的方式,可以根据需要修改。比如,在之前的一个项目中,涉及到了
“根据当前网络流量自动扩容带宽” 功能,简单来说是
“当前云资产带宽使用率达到X时,自动通过控制器对云资产所享有的带宽进行扩容”。当时的环境没有Ceilometer
,使用的方案是 在宿主机上装了 Zabbix
agent,对所有网卡实现自动发现,然后监控并在触发阈值后,传值调用
QOS的REST API,当时传的值,就是具体的 NIC设备名,而不是 VM id。

  • case 2

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

 

还没有完,因为对VPC内的云资产来说,默认网关是 x.x.x.1
,意味着在不改动云资产内路由表的情况下,发往 192.168.3.0/24
的数据包都将发往 x.x.x.1
。所以我们需要对三个VPC的路由设施添加路由表,将数据包转发至 x.x.x.99 。

在系列的上一篇,

澳门新葡新京网址 5

逻辑原理在上一篇中介绍的比较详细,主要就是通过 OpenStack API
找到云主机的虚拟NIC设备所在的宿主机,通过paramiko到宿主机上执行写入TC规则。

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

在对端:

# 加载模块
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

澳门新葡新京网址 6

软实现GRE隧道打通的简单示例:

在有其它SDN控制器的场景下,通过Neutron 加载不同 driver
实现对控制器的调度,也能达到效果。

软实现IPIP隧道打通的简单示例:

但我们也可以利用 OVS 的特性,将以有这个需求的VPC内网络用 VLAN
组网,实现基于物理 VLAN 交换机的跨物理服务器二层虚拟网络 ;或是 仍用
VXLAN 组网,但使用支持 VXLAN 的物理交换机来扩展原本架构。

 

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

之后,便可测试OpenStack VPC内的这个网络到右侧已有网络的打通互访效果。

# 加载模块
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

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

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