中国IDC圈2016年9月6日报道，9月1日由工业和信息化部指导，中国信息通信研究院、中国通信标准化协会主办，数据中心联盟承办的“2016可信云大会”在京隆重召开。在可信云服务性能和运维论坛上，UCloud高级架构师叶仲华发表了题为“公有云可用性保障之可用区架构解析”的演讲。以下是演讲全文：

UCloud高级架构师 叶仲华 

大家好！今天来跟大家做一些简单的分享，主要是讲到公有云在可用区方面的架构体系。我是来自UCloud公司的叶仲华。

可用区这个概念最开始是来自于像AWS，AWS实际上是公有云包括云服务的鼻祖，我们作为国内公有云服务商，也是非常认可AWS相关的技术。可用区和区域的概念，在AWS他们已经实施了，已经在行业里面算是一个实施标准，所以很多概念基本上是借用AWS实施标准的说法。这里面有一些同事对于可用区和区域的含义并不是特别理解，简单来讲，对于公有云服务商来讲，当你的业务上到一定体量，你是难以承担一个地域数据中心故障，引起用户业务的全部挂起的。这种故障的时长和对于用户业务的影响，基本上是客户也好，云服务商自身也好，都是难以承受的。所以AWS自身来讲体量会比较大，在最开始的时候已经用了可用区和区域的概念，我们也在今年四月份全面切到可用区的概念了。

我们先不提可用区和区域两个概念，我们先看公有云服务商自身的数据中心的结构，实际上大家建数据中心的时候，就是去各个地方选数据中心的机房，为了能够在多个数据中心机房里提供相应的服务，你需要把不同数据中心内网打通，当你机房数量会比较多的时候，大家都要走到一个双栖型结构，每个数据中心通过光纤连到数据中心节点，这样可以实现互相的通信。对于公网，最终的总体公网出口节点就应该在Pop节点上。对于可用区来讲，其实并不是数据中心的概念，可用区更多是一个逻辑的概念，可用区是最终在公有云控制台能够暴露给公有云用户的，实际上它去选择一个可用区，最终它的资源必定会落到某一个具体的数据中心。但是作为我们云服务商来讲，可用区和数据中心之间的映射关系，我们是可以调整的，所以这里有一个表格，这个表格非常典型的，第一个用户它的可用区是DC1，DC1、2、3是不一样的数据中心，也就是说，用户选择的可用区数据中心是不一样的，另外是一个可用区包含多个数据中心，为什么不同用户上来可用区和数据中心映射不是对应的？这个主要是公有云服务商为了自己进行容量管理，不然的话每个用户对应都是死，大家习惯上来就选A，这样你就会把一个数据中心资源压满，别的数据中心是空满，这是容量管理。

第三个例子是可用区A和B，都是属于同一用户的，必定它的物理区是在不同的数据中心，要不然你的容量就没有了。在可用区的特性我们实施之后和实施之前，实际上它是有一些不一样价值的，这张图主要想讲的意思是，前面所讲的含义是可用区具体的逻辑概念，它实际上是和数据中心耦合的。但是如果你只是做一个节耦合，只是为了数据中心的容量管理和机房的容灾，你不需要有别的特性，也不需要拿出来说什么，因为这是非常基础的，数据中心到一定规模以后大家就要做容灾考虑。为什么可用区对数据中心带来高可靠性，主要是它有很多网络层、服务层相关的功能特性。比如在EIP，EIP是公有云的说法，它是随时可以和底层资源进行绑定和解绑定的，在不起用可用区功能之前，实际上IT本身有服务商属性的，也意味着你是某个数据中心IP，意味着你的物理位置就在数据中心，所以你要想在这个机房宕了，IP还能使用，那你就要跨可用区在使用。类似相关的是外网防火墙，也需要做这样的工作。还有你用对外提供的业务IP，实际上后端有很多实体服务器在的，你肯定会用公网负载均衡，它也是要求你具有一个地域级的属性，不能够跟某个数据中心真正来绑定，所以负载均衡也是需要有跨可用区的能力。共享带宽实际上是UCloud很重要的产品，相对于公有云来讲，大家比较常见的国外服务商基本都是按流量付费，国内服务商是按带宽付费，基本上有一个IP，要购买带宽对应的大小，对我们来说，我们在这个基础上，除了流量和带宽付费之外，我们还提供一个共享带宽的模式，用户可以灵活分配自己在公有云上的，比如十个IP，你可以把IP额外付费，然后把十个IP大家一起消耗的带宽进行总体付费，这样可以降低你的带宽成本。

还有其他混合云和UTB的高可用，就是说除了网络层以外还有其他云服务化的标准产品，都可以跨可用区使用。比如我可以把我的数据库建在一个可用区主库，从库建在另外一个可用区，从而实现跨可用区的同步，这时候你的一个可用区挂了，你的数据可以在另外一个可用区承担业务。我讲一下EIP怎么实现跨可用区的使用，在原来的时候，大家能看到这个pop节点，pop节点是我们整个区域的核心位置，但是外网核心，在我们没有做可用区改造之前，实际上它的物理位置，应该是位于我们可用区某一个或者几个数据中心的内部，意味着你这边的主机应该在下面，然后通过你的接入服务，这主要是做静态NAT，让你能够出网，然后通过外网核心公网出去，这样使得IP属性实际上跟可用区A存在绑定关系。所以这里来讲，我们实现了第一个方式就是在架构上有所改造，把外网核心位置从可用区里面挪出来，挪到pop节点位置，同时我们加了一串服务，就是UCloud自己的虚拟边界路由器，都是拿服务器搭的一套集群，这样一套集群实际上它最多是可以有32台服务器组成，每台服务器是万兆网卡，万兆网卡里面吞吐向都可以实现双向20G的吞吐能力。PBS是在20兆PBS，一般我们讲万兆限速是14.88兆PBS，基本上是64节的，所以基本上可以达到非常小包的限速能力，之所以能够达到这样的性能，实际上是使用了InterNAT的相关能力。我们会有一连串的产品代码部署在这个上面，当你的业务流量，云主机访问公网的时候，我们会知道云主机的流量，实际上是它的网络流量会通过OVS虚拟交换机，到达宿主机的网卡，我们通过NP+1，最后通过NAT驱动，最后送到NAT服务器IP。也就是云主机刚刚讲多的网络流量，出外网都会通过宿主机NP+1打到这儿来做服务，做完服务之后会送到URL，改造之后会做它的服务，由NAT服务再打一层隧道送到pop的URL节点上。刚才讲的是出去，那回来呢，在这块会根据用户IP直接送入到接入服务上去，如果这个机器宕机了，整个数据中心挂掉，实际上用户肯定要做介入操作的，你肯定要把原来的弹性IP绑在主机，然后进行解绑，再绑到一边的服务器上去。因为你只是宕机的，你需要做重新映射的调整，在另外一个可用区就可以用了，这个方式就是实现了在数据中心宕机的情况下，还能够有非常合理，非常顺畅的公网访问途径。

第二跟大家分享的是负载均衡，负载均衡跟EIP也是类似的，负载均衡服务的位置实际上也会要座落在某一个数据中心里面，实际上我们每个数据中心都有相应的负载均衡，只不过我们原来公网弹性IP是绑在云主机上，现在公网弹性IP是绑在可用区上，这个时候一旦某个可用区挂了，公网负载均衡也是可以做到把公网弹性IP直接映射到这个可用区负载均衡上，在负载均衡里面配的文件也是整个区域共享的，这样就使得你即使一边的数据中心挂了，同样IP和负载均衡这里都是可以做到很快速切换的。

另外跟大家分享一点，在网络里面的共享带宽，共享带宽对于我们来讲是自己的特色产品，原来的实现方式是在可用区里面，会做也是有这种每一个IP带宽进行采集，然后实时动态要去统计用户账户总体使用带宽大小，一旦达到可购买的阈值，要按照各个IP去限速。在切到可用区架构之下，因为我们这时候整个网络级别已经提到区域的级别，所以我们共享带宽也应该提到区域共享带宽，我们应该怎么做共享带宽从可用区到非可用区的拓展呢，我们有讨论过两种实现方式，一种实现方式是可能共享带宽更多是计费和策略相关的，我会统计上报带宽消耗量，跟统计计费系统联动，当你超过带宽之后下发联控策略，控制你的带宽，如果你的服务宕机了，你不会主动加一个用户带宽策略，实际上用户访问是没有影响的。所以我们第一个考虑方案是把共享带宽相关的计费和控制策略部署在某个数据中心机房，或者部署在整个区域机房里面去，把它的规模做到很大，这是我们最开始的想法。但是后来认为当数据中心级别，数据中心数量越来越低，包括AZ数量越来越多的时候，实际上这不是可扩展的方案，我们最后的实现方式是，在每个可用区里面，同样还会包含它的共享带宽计费系统，每个可用区都有一套。在区域层面我们再做一套，把每个可用区里面就好像三个IP一样，这时候再把它的结果以一定时间的上报，汇总到区域级别，区域级别再进行整个系统对接，策略流表下达控制。所以这样的话是一个层级概念，层级概念扩展性就会很好，容灾性也会很好。现在我们已经能够实现的是，在一些云服务产品上，比如说主机是最基础的，像DB，缓存，对外存储，数据仓库，还有hadoop，这些产品我们也要逐步迭代加入到AZ里面，从控制层面你可以选择把这些产品主动放到每一个AZ，每个AZ之间的通道建立，都是由我们后台系统完成的。

对于再下一步的计划，在于网络更精细的链路控制上，有一些用户的自定义网络的功能，当然现在也有，可能我们到时候做的力度会更细。包括我们自身托管混合云也是我们非常有得色的产品，现在已经加入可用区的架构，后续我们也会加到我们的VPC架构里面去。这是某个区域的计划，某个区域实现的方案。另外可用性还表现在跨区域能力上，对于我们现在来讲，我们已经实现了在华北、华东、华南区域实现跨程专线，三角形的环网，以及做到内网跨区域互通，包括链路层的切换，路由层的冗余，带宽也是弹性的，所以这些层面我们应该在国内公有云服务商里面，包括国外公有云服务商在国内对比的话还是处于领先的，另外海外也有香港专线，这是我们和大家分享的我们作为公有云服务商，在可用性保障下，用户最感知明显的就是网络稳定性方面所作的工作，希望大家后面在做跟网络相关的方案，大家可以考虑和对比的细节点。谢谢大家！