公有云网络关键技术

By 张玉坤@百度

摘要：网络技术的发展为今天的互联网行业奠定了基石。而伴随着大规模分布式系统系统的发展，从并行计算的专有网络，到各种分布式计算/存储系统，再到现在的云，网络已经成为最难管理和控制的分布式资源与基础设施。云计算给基础设施带来了巨大挑战，而网络本身的架构、模型迭代演化还很不成熟。本文将一一列举公有云网络中的关键技术问题进行剖析，给出一些建设性思路。

云是现在非常火热的话题，从云的类型上有可以分为私有云、公有云和混合云。先从几种云的特点说起。私有云的核心是资源专有性，是为一个客户单独搭建的，客户拥有独立的基础设施资源并有较大的控制权来部署和管理服务。从这点看，云服务商为客户定制的专有网络是私有云，而传统的企业自己搭建的网络和服务的模式也可以认为是私有云。公有云的核心是共享，通过平台资源共享的模式为客户提供灵活、弹性、稳定、高性价比的服务，公有云也是云行业里最活跃最能体现云的精髓的部分。混合云是介于二者之间，网络需求也更为复杂。

公有云对网络的要求

作为出身传统网络的工程师，或者说专为一家公司做私有云的工程师，在开始做公有云的时候，往往挑战还是蛮多的。首先看公有云业务对对网络的有了哪些新的要求。

业务需求多样

传统网络设计，只需要考虑支持一个业务或一个公司内为数有限的几个业务。由于业务数量局限性，并且往往业务开发运维人员在技术、平台、工作习惯上的延续性，对基础网络提出的要求也是相对稳定的。公有云网络环境下，客户来自各行各业，各个客户由于自身业务特点、产品架构、已有的技术沉淀、甚至技术人员习惯爱好各不相同，因此我们的网络架构需要能满足多样的需求，有的客户要外网，有的不需要，有的需要低配置机器，有的需要高配机器、专属机器甚至专属物理机。

稳定性要求高

稳定行体现在两个方面。其一，对于传统网络，尤其是有一定规模的业务，可以通过集群化的服务部署来克服单点故障带来的灾难性影响，比如某公司在08年的时候就将全网服务器统一成单网卡结构，业务的冗余靠集群的分布式部署来实现。这点对于公有云上就不现实了，一个租户可能规模很小只有少量机器，如果发生故障会对其业务带来灾难性影响。其二，面向的用户不同，传统网络面向的是公司内部的运维人员，网络工程师可以和应用运维人员紧密协同，对于异常有较强的处理能力和较高的效率。公有云网络场景下，面对的是外部的客户，上帝都是挑剔的，客户更关注服务的稳定性表现，更要命的是，客户有多个选择，如果稳定性做不上去就可能流失客户。

弹性扩展

传统网络的需求，通常具有计划性和可预见性，在扩展性方面即使没那么弹性，靠人工来实现扩展虽不是一个高明但可能还是能解决稳定的，但是在这个思路到了公有云的场合下就明显行不通了。一方面原因是在每个客户都分秒必争的竞争环境下，满足客户的需求要快。另一方面，网络架构要保持相对的稳定的状态下能够实现平滑的扩展，扩展要对客户透明，没有客户愿意陪着一版版重构迭代。

公有云网络解决思路

对于公有云场景下面临的这些网络问题，需要如何来解决呢？下面分别展开探讨一下。

多样性需求

面对业务的多样性需求，从网络设计的角度上需要能找到一个合适的套路，以不变应万变。将各式各样业务的网络需求从功能需求上进行拆解，基本可以分为：大二层、VPC、弹性IP、负载均衡、防火墙、VPN、专线…在一个公有云的网络里实现了了这些基本的网络功能组件，就可以应对大部分的用户需求了。每个功能组件如何完成，需要结合实现技术特点和已有技术积累背景。

比如为实现大二层，有比较多的技术方案，如MPLS VPN、Trill、Vlan、Vxlan等，MPLS需要中间承载的网络支持MPLS，Trill虽然可以规避STP防环带来的资源浪费，但仅适用于在数据中心内部，Vlan可以实现大二层但vlan数量限制了支持的租户规模，Vxlan这样的overlay的技术无疑是目前实现大二层比较成熟应用较广的技术，扩展了vlan数量，又可以通过Mac in IP的方式实现三层网范围虚拟机互通和迁移，从而保障业务连续性。

为实现VPC和弹性IP，需要对物理机IP、虚拟机IP、EIP等IP地址进行合理的划分和映射规划，同时需要考虑在如何实现虚拟机和物理机共存的情况下如何实现VPC互通。

为实现专线接入，需要综合考虑客户的多种可能需求，比如不同运营商线路的进入、不同的线路速率、不同的建设模式（客户建设、云服务商建设）、不同的资源类型（裸光纤、传输电路）等，设计少数通用的传输接入点和预定的支持模式，以便于在用户有新需求时可以从容应对。

高可靠性

可靠性是公有云网络的重中之重，很多工作都是围绕这个目标来开展的，分别从物理网络、Internet接入、Anti DDoS、多AZ／Region等方面来探讨。

为了避免在单台架顶交换机故障时对业务带来的影响，大部分公有云的物理网络设计成双网卡上联模式，两条链路使用链路聚合技术对服务器呈现最简单的逻辑。架顶交换机采用二虚一的技术，如堆叠、MLAG等，实现网络接入层的冗余。同时，二虚一技术带来的交换机状态同步，自动化的操作也需要引起重视。在带宽方面，为满足正常的通信以及存储、镜像的快速数据传输，当前主流服务应当至少配置万兆以上网卡。

由于用户对虚拟的管理以及对外提供服务都是通过Internet来实现的，因此用户对Internet的接入稳定性格外关注。在Internet接入方面，BGP是做公有云的刚需资源。在业务规模较小时可以先在一个地域接入BGP提供商。在国内，应优选电信、联通、移动三家运营商接入，结合成本和互备的需求设计几家运营商的穿透策略。如果要选择第三方的BGP提供商的资源，也需要重点关注上游运营商的接入数量、BGP策略、高峰期负载等因素。在业务发展规模较大时，应结合多region来部署多地域Internet出口，并实现跨地域的Internet出口冗余。

Anti DDoS基本是所有云公司都面临的问题。由于云上的业务比较繁杂，很容易引入一些易受到攻击的业务导致DDoS攻击非常频繁。在BGP出口又非常宝贵的情形下，很难储备大量的带宽来抵抗攻击，并且也会有长时间攻击带来天价账单的可能，另外一个业务受攻击如果资源耗尽会同时影响到别的租用。因此从上游运营商来截断攻击流量成了唯一的出路。目前主要的运营商都有提供anti DDoS服务，服务机制上有些不同。电信的云堤系统比较成熟，由电信集团提供服务，可以提供全国范围的流量清洗服务，接口统一对接相对方便。联通和移动没有集团范围的服务，但大部分省份可以提供类似服务。另外一种防攻击的形态是将攻击流量牵引到一个具有较高带宽和清理能力的高防节点上，而不至于将流量粗暴的丢掉。

为进一步提供可靠服务，应提供多region和多AZ的资源类型供用户来选择。区域是指全球范围内的某个物理节点，每个区域由多个可用区组成，可用区由一个或多个分散的数据中心组成，每个都拥有独立的配套设施，其中包括冗余电源、联网和连接。可用区能够提高生产应用程序和数据库的运行效率，使其具备比单个数据中心更强的可用性、容错能力以及可扩展性。多region选择更侧重独立，同区域的多region在保持独立的同时有更多的协同属性，因此距离上不能太远以免网络延时太大。

弹性扩展

俗话说“天下武功，唯快不破”，在做云的时候也要求我们能快速的满足客户的需求，才能在激烈竞争中占得优势。这就对网络的可弹性灵活扩展提供了更高的要求。

弹性扩展思路主要在几个方面：

• 可水平扩展，集群化思路解决个体性能突破的难度

  单台服务器、单个网络设备的性能突破往往需要较长的周期，过多依赖个体的性能提升节奏太慢，需要借助集群的思想来提升整体的性能。如负载均衡系统、DNS系统、Vxlan网关路由器等都是非常典型用集群的思路来提升整体服务能力的案例。

• 将功能推向末端，核心网络轻装前行

  借助分布式系统思想，将大部分的网络功能尽可能的推送到网络的末端，让最不容易改变的核心网络保持轻量的配置、负载，才能支持长期的迭代。比如前面提到的vxlan网关，可以将其功能下推到OVS或物理交换机上，让更易扩展的资源来完成大部分的工作。

在探讨了网络设计方面的几个关键问题后，还有一个非常重要的课题，那就是运维。

• 运维边界

  从运维模式上区别于传统网络运维。传统网络中，网络运维和业务应用运维有着比较清晰的边界的，排查问题的时候基本上分头排查就可以定位问题。公有云场景下，排查一个问题要涉及物理网络运维、overlay网络运维、ovs、负载均衡、EIP等多个环节，涉及多个方面的团队互相配合才能完成这个工作。如果配合的很好，那么自然没问题，如果多个团队有一点配合不默契，整个问题定位效率就会大打折扣。并且这个过程中大家职责也不够明确。因此，公有云网络运维需要一个专注公有云的运维团队来支撑才能更好的发展。

• 运维技术

  在运维技术要求上，公有云的网络也提出了更高的技术要求。传统网络的ping、traceroute、show故障排查三板斧在公有云的场景下显得力不从心。比如排查虚拟机间互访丢包，是丢在虚拟机内、ovs、物理交换机还是vxlan网关了？用传统的方法就不那么好排查了，因此需要在网络运维工具、可视化运维平台等方面进行持续建设，用SDN理念来实现运维效率的提升、运维手段的丰富和运维模式的升级。

在探讨了公有云的网络设计及运维问题后，最后也愿在风起“云”涌的时代，网络技术能在爱网络、爱技术、爱生活的人手中得到更长足的发展。