编者按：UCloud 最新发布了名为“Sixshot”的可用区特性，用UCloud VP陈晓建的话说，“可用区就好比云计算的太祖长拳，看似平平淡淡，但要打得好着实不易。”太祖长拳属于南拳流派，共有四套拳路，讲求一胆、二力、三功、四气、五巧、六变、七奸、八狠。有鉴于此，解密「云计算的太祖长拳」系列将在接下来的三篇内容里，详细介绍UCloud可用区项目的“一胆、二力、三功”。
本文是解密「云计算的太祖长拳」系列的第一篇，将全面解析UCloud可用区特性技术内幕，阐述基础网络的改造和外网新特性技术实现。在项目研发过程中，UCloud团队不因循守旧并力图有所创新、敢于打破常规改变一些已知的不合理设计，在编者看来，改革和创新皆需要胆识，本文作为系列的首篇，选太祖长拳之“一胆”开题。
从本文起，我们将会推出一个系列的分享文章，详细介绍为UCloud可用区项目中所涉及的软硬件技术实现，包括基础网络的改造、NFV虚拟网关的实践、底层SDN控制面和数据转发面的演进以及建设在新老架构间平滑迁移海量用户数据的运营能力等各个方面，分享该项目中的一些心得和经验。
本文是这个系列的首篇，我们将介绍UCloud为支持可用区特性对基础网络所做的改造以及新架构下实现的外网特性。
本文大纲如下：
基础网络改造
可用区重点功能实现
EIP支持跨AZ漂移
ULB支持跨AZ后端RS
共享带宽支持跨AZ的EIP
可用区核心模块UVER技术实现
结语
基础网络改造：环网和POP点
从2014年起，UCloud就开始致力于为分布各个地区的数据中心建设高可用高带宽的同城环网，其主旨设计思想就是将地理位置相近的多个数据中心（Data Center, 以下简称 DC）通过“双星型网络拓扑”结构连接起来，从而使任意两个数据中心之间都有高速、可靠、并具备全量冗余灾备能力的基础网络连接，如下图所示：
从图中可以看出，同一Region内的任意一个DC都是通过多条专有光纤和两个POP点相连。外网通信则是通过在POP点和各个上联运营商之间建设的BGP 线路来保证的。任意两个DC之间都有两条全量冗余的逻辑线路（物理链路会依照现实的带宽和冗灾需要进行扩容），因此即使一个POP完全不可用，DC和DC间，DC和Internet间的网络连通也能保证联通性。
另外，由于在POP点和各大上联运营商都建立了BGP peering，因此在某条运营商线路质量不佳或者出现中断的时候，可以通过调整BGP广播和路由的配置将用户的流量临时调度到其他的线路上去，保证网络的正常工作。
对于云计算服务商而言，具备同城多地的部署和冗灾能力是必经之路。这样的基础设施的设计和建设的能力，是一个IaaS服务商发展到一定规模和阶段后必然的选择。当然，所谓的一个“地域”（Region）的建设不是随意的，组成一个Region的数据中心除了单独在资质上需要满足各个方面的条件（供水、供电、空调、湿度、防火、防震、基础网络等等）之外，还要在协同组网上满足整体的需求，比如从DC到POP点之间的网络延迟在0.5ms以下，DC与DC之间的网络延迟在1ms以下，以及DC到POP点之间的带宽要求等等。
在可用区项目的实施过程中，我们对几个Region的基础网络都做了大量的变更以满足我们的建设要求，比如POP点的建设、带宽的扩容、内外网核心的分拆调整等等。现在在华北、华东、华南，以及亚太等主力地域，我们都已完成了“双星型”POP点的建设。
有一点需要注意的是，数据中心是一个物理概念，而可用区是一个逻辑概念，两者之间不一定是一一映射的关系。一个逻辑上的可用区（AZ）可以包含一个或多个数据中心（DC），只要这些组成同一可用区的数据中心之间的物理环境是符合我们建设标准的：
可用区重点功能实现
在一个Region内部署多个AZ并通过低延迟且全量冗余的“双星型”拓扑结构进行互联，只是满足了我们后续对可用区下平台能力改造的前提条件。在可用区产品介绍中，我们已经列举了在可用区框架下对应用服务跨地域互通、冗灾、平滑迁移等方面的一系列特性支持，如下图：
我们在这里着重针对EIP、ULB、以及共享带宽三个产品做一个详细的技术层面的剖析，看看在可用区实现背后蕴含了哪些技术细节。
EIP跨AZ使用
在原来的底层网络架构中，外网核心 (DC Core) 是下沉到每个数据中心内的。也就是说云主机在访问外网的时候，首先通过内网达到外网接入服务集群，然后报文经过处理后再经由外网核心选择合适的对端运营商线路访问Internet。
然而，这样的架构决定了用户使用的EIP (公网IP地址) 是无法跨DC漂移使用的。 因为上游的网络运营商一直只会和云平台之间动态交互段路由或者使用更简单的静态路由、而很少会支持云平台向他们广播全量的BGP明细路由，这么做的成本开销太大；另一方面，即使运营商愿意支持BGP交互全量明细路由，云平台自己的核心路由器也未必能支持那么大量的/32的明细路由（当然云平台可以选择购买更昂贵的高端路由器）。
因此，支持单个外网IP这样细粒度的跨DC网络流量调度一直是个难题——在实际实现中，我们发现不少友商使用的是一种变通的办法：即，不追求全部的公网IP地址都能跨可用区漂移，而是划分出一个特定地址段来，这个特定的IP段中分配的公网地址是具备跨AZ漂移能力的。比如AWS EC2 所提供的Elastic IP就是这样的一个设计。只不过这些特殊的“弹性IP”在使用中可能会造成一定的困扰：首先用户需要申请专门的EIP，然后在使用时需将新申请的Elastic IP绑定到主机上，但此举也会同时将原主机上绑定的公网IP销毁，使用不方便之余，原有的IP也无法再找回，若有备案等原因导致原有的IP有一定特殊性必须要保留，这样的操作必然会带来更多的不便。
需要声明的是：这是我们根据友商所提供的产品形态，由此对其后端的实现逻辑进行的推断，可能并不一定正确，欢迎读者的讨论和指正。
我们在对EIP可用区功能的扩展中，首先确定了“简化EIP概念”这一设计主导思想，坚决不引入第二类可能造成混淆的外网IP概念。在此前提下，我们决定将DC的外网核心上移至POP点，将和运营商之间的BGP peering终结在POP点。外网接入服务集群仍然分布式部署在各个DC中，它们能独立地为所在DC中的UHost云主机提供外网流量的报文转发处理能力。外网接入服务对报文处理的最后一步是将报文封装后通过overlay的隧道送达POP点内的虚拟边界路由服务(UCloud Virtual Edge Router or UVER，关于UVER我们会在下文详细介绍)，再经由UVER剥离overlay封装后送至外网的运营商线路上。UCloud有多种的外网接入服务，以下我们以NAT服务为例来看一下整个数据转发面 (datapath) 经过的每一跳上的处理流程（关于UVER的处理动作，我们会在下文详细叙述）：
我们来感受一下可用区改造前后整个架构上的区别：
图：可用区改造前整个架构图
图：可用区改造后整个架构图
可以看出，通过将外网核心的上移，我们可以通过自身的SDN逻辑（即UVER）将地址（源或目标）、将任意一个EIP的网络流量自由地在不同的AZ之间调度，从而实现了EIP的跨AZ漂移。
ULB负载均衡绑定多个AZ的后端RS
讨论完EIP之后，我们接下来看看ULB外网负载均衡的场景。从架构上而言，ULB和EIP是很相近的：
通过UVER（(UCloud Virtual Edge Router，虚拟边界路由）的调度，同一个ULB上的外网IP可以将流量分发到不同AZ内的后端RS上，这样的跨机房流量均衡和容灾的能力是很多应用层的程序架构所希望拥有的，也是云平台必须提供支持的。同样，我们来看一下整个数据转发面上各个节点的具体处理：
值得注意的是，如果需要的话，UVER甚至可以将去向同一个目的EIP的相同端口的流量通过一致性哈希算法ECMP到不同的ULB服务器上从而大大提升单个EIP上可以承载的总体带宽。也可以将去向同一个目的EIP的不同端口的流量分发到不同类型的ULB服务集群。例如，80端口分发到七层负载均衡，443端口分发到四层负载均衡。这是UVER这个虚拟边界路由服务通过SDN的方式给平台带来的额外的弹性处理能力。
共享带宽支持不同AZ的EIP
共享带宽是UCloud平台上一个比较特殊的带宽产品，它允许多个EIP共享一个带宽资源，后端控制面的程序在必要的时刻会根据每个带宽资源中包含的所有的EIP的实时使用数据来调整带宽的分配。在可用区之前，共享带宽只能作用于隶属同一个DC下的EIP组。但由于在可用区下，EIP是可以跨AZ的，因此很自然的，共享带宽的功能也必须要能支持跨AZ的EIP组。
原先DC级别的共享带宽服务的架构比较简单：
图：原先DC级别的共享带宽服务的架构
在每台主机上，SDN Agent会采集UHost云主机实时的带宽使用数据，然后上报到后端的Redis缓存服务中，控制面的管理程序 (UTraffic Manager) 根据上报的结果做实时的统计并计算需要调整的带宽设置，然后通过SDN Agent来推送调整信令。
在可用区中，由于每个AZ间物理网络都是可以直连的，因此我们最初的想法就是将Redis缓存和UTraffic Manager进行扩容即可。但在进行了一番计算推演后，我们推翻了这个设计。主要原因在于，如果我们的架构在一个Region内只使用一套共用的后台缓存服务（当然为了容灾起见，我们会将Redis的集群分布在多个AZ内）的话，整个Redis缓存服务需要承载的峰值流量将是巨大的。此外，在考虑了每个Region后续的扩容计划之后，这个矛盾只会在日后更加凸显出来。因此我们决定对整个后台架构做一次分层的拆分：
图：共享带宽服务新架构
在这个新架构下，我们在每个AZ会部署一套Redis服务。主机上的SDN Agent根据AZ属性，上报到各自AZ的Redis。AZ-wide的UTraffic Manager会负责拉取本AZ的Redis数据，进行第一次本地的汇总计算后，将共享带宽的EIP带宽信息定期上报到Region-wide的UTraffic Manager。Region-wide的Manager，负责计算最终的实时带宽使用情况，然后决定流控策略。AZ-wide的UTraffic Manager会从Region-wide的UTraffic Manager处获得指定的EIP的流控规则，然后主动向SDN Agent推送。这个新架构很好地平衡了我们对实时性和系统可用性的要求，也为之后的水平扩展做了良好的铺垫。
可用区的核心模块：UVER
跨AZ的网络流量调度能力是整个UCloud平台SDN基础架构上的一个简单的应用，但这一切的关键都在于拥有一个具备高性能处理能力和自适应容灾能力的边界转发服务——这就是UVER（UCloud Virtual Edge Router）诞生的初衷。这也是本文介绍的最后一部分。
为什么需要UVER
在UVER诞生之前，虽然所有的EIP访问都已经集中到了两个POP点机房，POP点仍然是通过配置C段静态路由的方式将EIP的下一跳设置为具体某个机房的外网核心路由器。而用户可以在同Region内任意可用区绑定EIP后，EIP的路由设置将不可能再通过静态C段路由的方式来设置，必须引入动态明细路由配置。而对硬件路由器来说动态路由的条目数是有限制的，虽然我们可以选择更高端型号的硬件路由器来提升支持的动态路由条目数，但是考虑到未来UCloud的快速发展会对硬件选型带来极大的限制，我们还是决定通过软件的方式来解决这个问题。
UVER实现细节
我们首先来看一下UVER的整体架构：
图：UVER的整体架构
UVER集群部署在POP点，向外网接入路由器广播C段路由，引导Internet流量进入UVER。UVER根据数据包的目的IP地址，查找内存中的明细路由表中的下一跳服务器信息。
进行内网标准的NVGRE封装后通过内网接入路由器转发到具体的可用区机房的下一跳服务器上。
下一跳服务器需要出Internet的时候同样通过内网标准的NVGRE封装后发送到UVER。
UVER服务器解除NVGRE封装后通过外网接入路由器发送到Internet。UVER采用无状态的路由模式设计，实现简单，容灾性能好。
UVER的高可用设计
总体而言，UVER从以下几个方面来保证集群服务的高可用性：
将一致性哈希算法应用于ECMP；
异地容灾；
分SET部署。
目前在同一个Region部署了多个UVER的SET，每个SET广播不同的C段EIP路由负责一部分EIP的流量。SET间互相独立，彼此不会互相影响。同时每个SET内包含2个POP点的服务器，每个POP点服务器的规划容量都能承载整个SET的业务。如果有部分EIP的流量特别大，将通过32位明细路由的方式，将该EIP的流量牵引到独立SET进行服务。同时在每个Region还有一个特殊的SET，称为隔离区SET。所有检测到突发不正常流量（DDoS）的EIP，将会被自动牵引到隔离区SET，防止影响其他用户的正常使用。
在选择转发目标时，UVER将一致性哈希算法应用于ECMP，从而实现了对后端有状态的服务集群的容灾支持。即，在后端服务集群中发生宕机时，在UVER这层能最大限度地避免全局性的影响（比如全局哈希移位之类的问题）——理论上，只有发生宕机的那台后端服务器上的连接会发生中断需要重连，而其他通过UVER转发的连接是不受影响的；另一方面UVER集群服务器本身又是无状态的，因此UVER集群内部发生宕机的话，其他服务器仍能正常地对所有经过UVER集群的报文进行转发处理。从用户的角度看，他们的连接是不受影响的。
UVER的性能
因为采用了DPDK技术设计UVER，UVER的单机转发性能达到20M pps，能够提供20G bps的吞吐（10G入、10G出）。单个UVER SET可以最多由32台服务器组成ECMP集群，能够提供最大320G入、320G出的吞吐量。而每个Region可以部署的UVER SET并没有限制。
结语
在本篇技术分享中，我们分别介绍了可用区架构下基础物理网络需要进行的改造，以及外网新特性的具体实现。第一期功能发布后，我们同时也在着力于新特性的快速迭代开发。比如，支持ULB实例本身跨可用区部署等。希望通过这样的分享，能够和大家一起学习和探讨那些我们乐此不疲的技术难点和解决方案。在下一篇连载中，我们将详细讨论和可用区相关的内网特性和改造的一系列技术细节，敬请期待。
关于作者
Y3（俞圆圆），UCloud基础云计算研发中心总监，负责超大规模的虚拟网络及下一代NFV产品的架构设计和研发。在大规模、企业级分布式系统、面向服务架构、TCP/IP协议栈、数据中心网络、云计算平台的研发方面积累了大量的实战经验。曾经分别供职于Microsoft Windows Azure和Amazon AWS EC2，历任研发工程师，高级研发主管，首席软件开发经理，组建和带领过实战能力极强的研发团队。