<b>摘要：</b>从传统it部署到云，人肉运维已经是过去式，云上运维该怎么开展？人工智能对于运维“威胁论”也随之袭来，如何去做更智能的活，当下很多运维人在不断思考和探寻答案。在2017云栖社区运维/devops在线技术峰会上，阿里云专家云登就为大家分享了云计算网络基础架构的实践和演进，精彩不容错过。
<b>以下内容根据演讲视频以及ppt整理而成。</b>
众所周知，云计算是以计算、存储和网络作为基础的。网络作为云计算的重要基石之一，其架构设计和演进是云计算发展的重要一环，而网络架构涉及可靠性、性能、可扩展性等多方面内容。架构是从理论设计开始的，理论设计和实践碰撞到一起，能否经得住考验，是否能够符合预期呢？厂商所提供的网络设备的高级特性真的是解决问题的银弹么？如何通过经典网络和vpc构建混合云，打通云上和云下呢？阿里云在以往的实践以及与用户的交互碰撞中遇到的问题又是如何解决的呢？本次分享中将与大家一起进行探讨。
<b>本次分享的目录</b>
一、常见的云计算网络架构
二、云计算网络的可靠性和故障定界
三、专有云网络的模块化
四、混合云构建的并网案例
五、云网络架构的演进趋势
<b></b>
下图所展示是一种常见的云计算网络集群架构。传统情况下云计算网络架构会分为三层：接入层、汇聚层和核心层。如下图所示，在接入层下面的两台交换机会进行堆叠，再下面会连接服务器，服务器一般会选择使用两个网卡进行bond之后以双上连的方式连接到2台接入交换机。在接入交换机和汇聚交换机之间也会有多条线路的连接，一般而言会存在二层或者三层的接入。对于带宽收敛比的设计而言，对于千兆集群可以采用1:1无收敛的方式，而对于万兆集群则可以使用收敛比为1:3或者1:2的方案，也可能使用无收敛的设计。从汇聚层再向上连接到核心层，一般情况会使用三层连接。
下图是另外一种比较常见的云计算网络集群架构，在spine节点和leaf节点之间可能会存在三层连接，而spine节点和core节点之间也可能会存在三层连接，这种网络架构相比于前面提到的架构而言，其扩展粒度要更细，可以细化到一组或者多组进行接入。
想必大家对于overlay以及underlay网络都有所了解，物理网络被称为underlay网络，物理网络搭建完成之后应该尽量保证网络拓扑是固定的；而对于overlay的网络而言，可以基于vxlan技术构建vpc网络，通过软件定义和控制器的方式可以动态地构建虚拟的网络。所构建的网络可以是一个或多个虚拟的网络，可以通过云上不同的租户去定义地址规划以及路由的规划，甚至还可以提供类似于高速通道这样跨vpc之间的互通。underlay网络的设计基本上就是前面所提到的接入-汇聚-核心架构以及spine-leaf架构，而对于overlay的网络则描述的是虚拟的层面，提供的实际上是虚拟的路由器和虚拟的交换机，包括其构建出来的可以接入像slb、rds、ecs、ocs等云产品的vpc容器。为什么叫做overlay呢？其实因为overlay网络是通过vxlan隧道的封装运行在underlay物理网络之上的。通过overlay逻辑网关去组织业务进行资源编排就可以构建出非常丰富的基于overlay网络的产品。
前面主要介绍了云计算网络的一些基础概念，接下来将会针对云计算网络的可靠性以及故障定位的方式进行分享。
对于云计算平台的物理网络而言，其可靠性可以分为以下的几类：
<b>多线路，</b>常见二层的lacp，也就是链路聚合，对于三层则使用等价路由。
<b>设备ha，</b>从体系结构来讲，分布式的多框、多插槽的设备能够提供多主控、多接口板这样的方式，还可以提供类似于堆叠技术和多机之间的双机热备以及多机的备份或者多机堆叠的方式，还可以提供vrrp的链路切换。
<b>探测和切换机制，</b>实际上在网络配置交付之后，如果远端出现了问题，为了解决链路上的负载均衡以及主备切换的问题，可以引入比如nqa+track这样的探测技术，这样可以针对静态路由的配置通过不同的优先级和nqa探测方式发现远端节点不可达的时候进行路由切换。除此之外，在探索到某台设备出现故障的时候就可以进行故障隔离，可以实现端口级或者设备级的故障隔离，保证流量可以走备份或者冗余链路进而避免流量中断，当然，这种情况下可能对于流量带宽造成一定的损失。
<b>巡检和监测，</b>针对于overlay和underlay的网络会提供主动探测的机制，还有对于设备的日常日志告警的分析。设备在运行中往往会报很多的日志和告警，将这些信息收集起来之后结合云平台的业务流量可以挖掘出很多故障的可能性、已经出现的故障还有对于未来可能出现故障的预判。还可以进行流量分析，并且基于此判断云平台的网络是否出现了一些问题。
如下图所示的是常见的网络集群故障点分布图，云计算平台的网络故障点主要集中在下图中标号的几个位置：
<b>标号1：线路故障，</b>比如服务器上连到tor交换机，也就是服务器上的接入网卡接入到交换机上时出现了网卡、线路或者是接入端口损坏导致线路上出现故障。同样的，从接入层到汇聚层，从汇聚层到核心层也会出现这样的线路故障。
<b>标号2：核心设备的故障，</b>核心设备的故障可能导致跨网络端口之间的流量损失，由此造成的影响范围往往比较大。对图中所示的网络架构而言，如果流量需要跨端口进行传输，就一定需要从接入层到汇聚层再到核心层再转入另外一个pod的汇聚层。
<b>标号3：汇聚交换机的故障，</b>一般情况下汇聚交换机采用堆叠的方式，可能会出现堆叠的分裂以及单台设备的故障，也可能出现整个端口流量上行的带宽减半或者是分裂以后导致等一些不可预期的后果，因此需要及时检测出一些故障并且及时进行隔离以及对于设备进行下线维修从而排除此类故障。
<b>标号4：接入交换机的故障，</b>接入交换机也会发生类似于汇聚交换机的故障，堆叠分裂或者单机故障则会导致下面连接的服务器出现问题。
<b>标号5：服务器故障。</b>
<b>标号6和7：像上述提到的堆叠出现问题造成的故障，</b>这样的故障需要通过日常的巡检以及网络设备自身报告故障的日志告警来发现问题并及时去进行相应的处理。
<b>以下是对于常见的网络集群故障点的详细描述：</b>
<b>线路故障。</b>体现为带宽的损失，一般通过多条线路保障，三层网络设备间通常用ecmp等价路由，二层网络设备间通常采用聚合lacp，提高可靠性。在实际情况下，在公有云环境中会发现：一旦网络集群规模大了之后，堆叠出现问题的概率就会变大，与此同时，二层的广播风暴和环路出现的概率也会变大，阿里云目前在逐步地考虑去掉堆叠并且去掉二层，这也可能是未来的发展方向。这样的目的是为了简化网络并提高网络集群的可靠性。
<b>dsw故障。</b>dsw是对于核心设备的称呼，由于所有的dsw之间不直接互联，它本身的可靠性只能依靠硬件框式分布式，多主控板（主备ha）、多接口板（上面说的多线路跨板连接）来保证单点可靠性，使用多台dsw，平时负载均衡，单台故障时互为备份链路。如果是单台dsw故障，将会影响带宽损失。
<b>psw故障。</b>也就是汇聚设备的故障，拓扑中有psw堆叠和去堆叠两种情况，如果是堆叠的，单台故障，上下连线依靠跨堆叠设备的lacp或者ecmp实现业务不中断（但带宽有损失），如果不是堆叠的，参考（2）的场景。如果是单台psw故障，影响的是下连的多组asw带宽损失一半。
<b>asw故障。</b>线上很多的asw都是堆叠的，目前阿里云也开始去堆叠，如果是堆叠的，asw下连服务器，服务器双网卡bond接入（lacp），如果是去堆叠的asw，服务器双网卡等价路由负载均衡。如果单台asw故障，影响的是下连的48台服务器的带宽损失一半。未来，阿里云新构建的集群会逐渐减少对于堆叠的使用，进而提高网络设备的可靠性。其实对于网络厂商而言，他们也会对于堆叠特性进行大量的测试，但是实际上由于堆叠特性十分复杂，因为其涉及到硬件、软件、内部检测以及协议的传输备份，也就是会涉及到很多跨框、跨设备的同步以及选举机制。由于堆叠特性实现本身就非常复杂，就会导致出现问题的可能性比像路由转发这样其他简单特性更高。而在云计算场景下海量的网络设备同时运行，就进一步提升了堆叠特性出现问题的可能性，基本上就会导致出现存在堆叠的场景下可能经常会出现问题。为了解决这样的问题就需要逐步地去除堆叠和二层。
<b>服务器故障。</b>可能体现在服务器网卡或者本身内部的应用系统的问题，服务器故障一般只会影响自己，范围比较小。
<b>psw堆叠分裂。</b>各自认为自己是主设备，为了减小影响，一般会配置dad双主检测，禁掉一边，影响为整个pod的上联带宽和跨asw之间转发带宽损失一半。如果psw堆叠整体故障，整个pod挂掉（各组asw下的48台服务器之间仍可互通），上连不通，跨asw的互连不通。
<b>asw堆叠分裂。</b>类似于（6），影响为一组asw下挂的48台服务器的互联或者上联带宽损失一半。如果asw堆叠整体故障，该组asw下连的48台服务器全部不通。对于（6）（7）的堆叠故障，由于厂商堆叠技术本身复杂，导致故障概率提升，再加上公共云使用的网络设备规模大，基数上去了就进一步放大出故障的概率，且影响范围大。因此网络本身的可靠性和故障位置，对于云产品来说影响的范围也是不同的，ecs之类的云产品能够打散到不同的asw、pod甚至az（跨网络集群），其可靠性指标也是不同的。基本上是打散的网络设备之间的层级越高，可靠性保证越高，但同样的网络延迟也越高。
那么怎样才能够及早地发现这些故障呢？其实可以使用故障主动探测的模型。在网络集群里面，可能会选择特定的接入设备比如像服务器，将其作为主动探测的机器，其探测的目标就是网络设备下面的其他服务器。
<b>建立的第一个简单故障主动探测的模型如下：</b>
一个tor下面所有物理服务器（例如48台）都同时出现大量丢包 --> tor交换机故障。
个别物理服务器出现丢包 --> 服务器负载问题/tor交换机端口队列打满。
到某个机房的大量物理服务器同时出现大量丢包-->汇聚交换机/核心交换机故障。
到某个机房的大量物理服务器出现少量概率丢包->汇聚交换机/核心交换机的个别端口问题。
每个机房最少只需要1台机器作为探测源，部署对业务网络影响小，icmp ping之类的只能做layer3的探测。
依照上述的故障主动探测模型就可以简单地判断网络出现故障的范围。
<b>建立的第二个简单故障主动探测的模型如下：</b>
通过选择不同位置的服务器作为探测源或者探测目标，发现不同层次的故障位置，多轮次组合。
要求每台服务器运行agent，并接受外部控制器指令，动态调整探测策略，可建立tcp连接并测试。
可以针对overlay和underlay网络进行探测，更容易模拟实际应用的业务流量特征，支持layer 4探测、时延计算。
第二个故障主动探测模型在服务器内部会增加一些代理agent，安装代理之后可以做到对于4到7层的探测，可以探测出tcp连接的情况以及其延迟和性能速率。同样的，探测模型也可以组合出不同的探测方式，在了解网络架构的拓扑之后就可以探测位于同一组接入交换机下面的两台或者多台服务器，也可以探测位于不同的核心交换机或者汇聚交换机下面的多台服务器。通过这种建模方式就可以知道当前延迟高或者丢包的场景下，网络的问题到底出现在什么位置。
<b>三、专有云网络的模块化</b>
上述提到的是网络体现在本身体系结构上的可靠性，比如分布式设备、支持主备ha、支持双机热备或者多机堆叠以及其他一些高级特性，这些都是从网络设备本身的角度而言的。除此之外，通过线路带宽的设计保证收敛比以及负载均衡，以此来保证云计算网络的可靠性。而通过日常的巡检和探测能够及时地发现故障，并在故障发生之后及时了解故障发生的具体原因并提供故障定位的方式，进而提高云平台网络的可靠性。
上述这些都是在公有云网络上的实践，对于专有云而言，又会存在什么样的差别呢？其实对于专有云而言，更多地会对其进行模块化的设计。公有云一般而言是可规划的，可以对于未来集群的规模、建设的地域以及网络架构的选择等进行规划。而对于专有云而言，客户的需求往往不能够规划出来，不同的客户所需要的业务的场景和诉求往往是不同的，这些在网络设备的选型、已有设备的利旧使用以及对于云平台功能的裁剪上都会有所体现，所以专有云与公有云上的的网络设计就存在较大的差别。
下图是专有云网络架构图，一个很明显的特点就是专有云网络会分成几个区域，最上面的是外部接入区，外部接入区包含了阿里云和isp或者用户骨干网出口的链接以及在其上进行安全防护的云盾。专有云网络架构图中间的dsw和下部的psw则属于dc区，也就是网络架构的核心区域。图中右面的综合接入区分为了两个部分，一部分是阿里云所提供的负载均衡、vpc网关以及ops相关的接入，另外一部分则是csw，实际上就是客户的vpc专线接入区，阿里云的专有云客户会有一些原来的物理网络需要与云上的vpc进行网络打通，一般会通过vpc的专线接入交换机的综合交换机接入进来。也就是说专有云网络的每一个模块都有一个相对独立的设计，所有的模块实际上都是作为半独立的部分，所谓半独立就是意味着可以进行独立的裁剪或者进行局部调整。专有云网络进行模块化之后能够带来的好处就是可以进行随意地裁剪，比如很多专有云客户没有连接互联网的需求，只需要一个完全的孤岛环境，这样就可以将外部接入区全部裁减掉。这样做所带来的优点就是首先简化了不必要的功能，其次减少了设备的采购，也就减少了用户不必要的网络成本。
<b>专有云网络架构其他方面的一些考虑与公有云存在哪些差别呢？</b>
<b>（1）专有云的网络架构源于公有云</b>
专有云基于公有云已验证输出的架构版本，进行裁剪和变更。既保证云网络架构是同构的，又引入灵活性和降低成本。
<b>（2）公有云的建设是可规划的，专有云则是按项目走的</b>
公有云的网络架构一旦确定，建设就有了标准，在架构整个生命周期内建设都需要按照架构设计进行实现，而且完全可以提前规划。专有云更强调的是可以进行细粒度的调整，其可定制化要求会更高一些。专有云的网络架构确定后，每个项目的客户需求不同，常常要求变更，最常见的是网络设备选型变更，网络拓扑也常有变更，例如拉专线、利旧原有网络设备等的需求，对于这些情况大多是case by case进行解决。
<b>（3）公有云的硬件和配置可定制化，专有云的硬件和配置尽量通用化</b>
根据架构演进设计，公有云启用的硬件可定制，且规划是一脉相承的。专有云由于面对的是不同的客户，需求不同，重口难调，架构设计往往需要考虑兼容性，要能利旧，客户常常要求将其已有的交换机资产用在云网络建设上。所以专有云的网络设备往往要求需要通用化，便于不同用户理解，降低用户后期运维的复杂性和学习的成本。
（4）架构支持的服务器规模
公有云的网络拓扑，一开始的考虑就是中、大规模的。专有云的需求规模各项目不一致，服务器少的项目只有几十台，而服务器多的项目又需要超过几千台以上，因此专有云的网络架构设计需要考虑s/m/l等不同规模，甚至要划分的更细粒度，以便兼顾云平台的稳定性和客户采购的硬件成本的均衡。
<b>四、混合云构建的并网案例</b>
一般而言，客户在建设专有云之后，可能也会对于自己的租户提供服务，或者自身也会存在部门的划分，希望每个部门也有自己的专有网络，并希望云上的专有网络能够和原有的云下物理网络进行打通。
<b>案例1：传统idc接入阿里云vpc</b>
下图是一个常见的传统idc接入阿里云并网的网络拓扑。图中左半部分是云平台的网络，图上的示例划分了三个vpc，每个vpc内部都包含了自己的云产品，也会有自己的虚拟交换机和虚拟路由器。图中右半部分表示的是客户原有的网络，这个网络可能会基于业务或者基于部门进行划分。那么如何将用户原有的网络接入到云上的网络，实现将业务从云下迁移到云上呢？阿里云会提供vpc的专线接入方案帮助实现传统idc与阿里云的并网接入。
<b>案例2：传统idc接入阿里云vpc--单租户多vpc</b>
下图中展现的是单租户多vpc的网络拓扑。图中左半部分是传统idc的网络区，客户原来可能是通过vlan划分不同部门之间的网络的，那么如何接入到阿里云的vpc呢？如图中右半部分所示的其实是一个专线接入设备csw，可以看到左侧的网络一般而言可以根据vlan的划分设计出接入的方式。如图中所示以vlan划分为x、y、z三个部门的网络，右边在阿里云网络区中也会相应地划分出三个vlan if接口，这三个vlan if接口会对应地接收客户这边的三部分的报文。客户idc中的三个vlan的报文通过trunk口上行到csw上以后，因为vpc网络可以进行vpc内的路由和地址规划，因此在csw交换机上可以划分三个vrf，每个vrf会根据入端口去确定后面的路由转发，比如vlan x的报文通过trunk口接收上来之后会终结到三层口vlan if x上。vrf一般都是通过入端口进行确定的，因此自然就会在vrf a中进行路由，这样就可以设计从传统idc网络到vpc上的路由以及从vpc到传统网络的回包路由。当报文通过vrf a路由到出接口的时候，vsi会进行虚拟的交换将当前的流量对应到某一个vxlan tunnel上去进行封装和转发，这样报文就会通过综合接入交换机lsw转发到vpc的xgw网关，之后xgw网关根据vxlan的id确定当前的流量需要引入到哪一个vpc中去，这样就实现了云下的传统idc客户网络和云上的租户的vpc的网络打通。
<b>案例3：传统idc接入阿里云vpc--多租户</b>
下图中展现的是另外一个例子：多租户的传统idc接入阿里云vpc的情况。这与公有云的接入方式比较类似，上一个例子实际上是专有云客户内部网络不同部门或者不同应用的划分并通过vlan的方式接入，而下图中例子则是专有云客户自己还有很多个租户需要接入，这样接入方式其实与公有云比较相似，多个租户可以通过三层的专线直接接入到vpc的接入点csw，后面的逻辑其实与上面的案例是一样的，通过入端口确定vrf之后，在csw内部可以将流量引入到不同的vpc中去来实现云下的网络和云上vpc网络的打通。
上述的实现方式在专有云的实践中经常遇到用户使用静态地址进行接入的情况，因此会需要静态路由配置，比如流量回包时会需要通过vpc到客户网络那一侧进行静态路由的指回。以下图为例，配置静态路由的csw是一个堆叠的设备，如果远端客户的网络出现了问题，比如光纤被挖断或者出现了设备故障问题，怎样去实现流量的切换呢？其实需要使用nqa + track的方式，需要定义两种具有不同优先级的路由，正常情况下会通过高优先级的路由传回客户的租户网络，当nqa探测到远端的设备不可达的时候则会通过track方式将路由切换到备用专线上来传回给租户的网络，这样就实现了远端故障时的流量切换。当远端网络主链路恢复之后流量还可以重新切换回来。这样就实现了云上和云下多链路vpc专线接入的情况下的静态路由链路。
<b>五、云网络架构的演进趋势</b>
未来，云计算平台网络架构演进的趋势主要如下图所示：
未来云计算平台上的网络会发生从经典网络到vpc网络进行切换；逐渐去除堆叠，从堆叠环境切换到独立设备，在一个比较大范围的网络使用场景里面减少堆叠带来的故障，整体提高云平台网络的可靠性；在underlay物理网络中逐渐去掉二层，因为二层经常会出现广播风暴或者环路问题，去掉二层则可以提高网络的可靠性；对于端口而言，会从原来的支持千兆和万兆逐渐过渡到支持25g和100g；对于物理网络的复杂度而言，会逐渐降低对于物理网络的依赖，逐渐将其复杂度下沉到服务器端，无论是vpc网关还是普通云产品的宿主服务器，都会将其对网络的依赖进行逐渐解耦，尽量减少因为网络故障给云平台带来的不稳定。