异地机房容灾解决的方案.docxVIP

UCLoud中国云三强: 异地机房容灾解决方案在本系列的第一篇文章里（ HYPERLINK /s?__biz=MjM5NDE0MjI4MA==mid=2656298815idx=1sn=3a4b53e1a007cf5503f572b1c9216f8bscene=21 \l wechat_redirect \t /_blank 解密「云计算的太祖长拳」系列之一“胆”：基础网络改造与新架构），我们详细介绍了为了支持可用区新功能，UCloud在基础网络建设和外网特性方面所做的一系列改造，其中包括基础网络的双星型拓扑结构和POP点的建设；EIP、ULB、以及共享带宽的功能跨AZ的使用；跨AZ流量调度的核心模块 - UVER (UCloud Virtual Edge Router)的实现等方面的内容。 本篇文章是该系列的第二篇，我们会着重介绍在可用区研发过程中，我们对UCloud公有云平台的底层SDN架构所做的一系列改造。这些改造有的是宏观层面的重构和演进，有的看似是局部的调整但实则是在亲历了运营一个大型IaaS平台所遇到的那些困难之后才审慎提出的一套解决方案。 Agenda: SDN底层架构重构 支持虚拟网络广播协议带来的架构变化 SDN封装隧道与流表的优化 结语 SDN底层架构重构（网元跨可用区的互访） UCloud IaaS平台上支持多种不同类型的计算节点，比如公有云上的虚拟主机（我们简称“公有云”），物理主机（简称“物理云”），以及托管区域的主机（简称“托管云”）等等。这些节点或者说网元在底层SDN网络的支持下互相间是可以在虚拟网络（Virtual Network）的层面上无缝地互相通信的，同时，虚拟网络也提供了租户间互相隔离的安全机制。这些都是IaaS平台所应具备的基础能力。在可用区的场景下，这些能力从用户层面看来还是保持了和从前一致的行为，但事实上，平台底层的物理网络以及SDN逻辑其实是经历了一次彻底的重构。为了更好地理解这次重构的意义，我们首先来了解一下原有的网元跨DC互通的实现： 如上图所示，在之前的架构里，不同DC间的两台主机的互访是要通过跨机房的软件网关（上图中的Gateway）来转发的。当然这里底层的逻辑还是通过SDN的方式来实现的，其datapath的路径如下： 这个架构虽然能提供用户不同机房的网元间互访的能力，但???整体上来评估， 它还是具有以下三方面的问题： 互访的SDN逻辑比较复杂：两个节点间单向就需要有6条SDN的flow，所有这些flow的下发都需要经过controller和后端manager的处理，然后要考虑鉴权隔离、跨账号互通等其他相关的场景。同时，我们还必须考虑不同网元间的各种场景（比如“公有云”和“物理云”跨机房互通，“公有云”和“托管云”跨机房互通等），那复杂度必然进一步增加。 跨机房互访由于需要经过两组软件网关的转发，那么其效率一定会受到一些影响（整个逻辑链路的网络延迟会有所增加）。并且，由于这些软件网关集群位于跨机房互通的关键路径上，它们自身的可靠性和容灾能力也是我们不得不面对的问题。 后续在各个相连机房不断扩容的情况下，跨机房网关集群也必须随之扩容。但作为整个链路上必经的中央节点，这个服务理论上将面临的是O(n2)的扩容压力（假设两边机房的节点数是n），这对整个系统长期的发展来看不是一个理想的状态。 对于大型的分布式系统，一般而言，复杂度永远是软件系统稳定性和可扩展性的天敌。我们设计的目标是在保证功能性的基础上，能尽量低去简化系统，把系统“做小”：a system achieves perfection not when there is nothing more to add, but when there is nothing left to take away. 在可用区的新架构中，不同AZ间的网元之间的互通不再需要通过跨AZ网关做转发，同一Region下的两个网元之间在物理网络层面上是三层(IP层)直连的，下图是可用区启用前后网络路径的对比： 如此，不同AZ的网元间互访的datapath就和同AZ的情况是完全一致的，这就从底层保证了用户可以在其虚拟网络中部署跨AZ的云主机而不必担心受到不同物理网络拓扑的限制或影响，而在虚拟网络之上的云主机与云主机之间是一个完全“点对点”直连的“大二层”拓扑结构，在这个框架下，用户可以无缝地获得跨AZ部署高可用应用的容灾能力。 对于物理云和托管云来说，情况略有不同，因为它们有各自的网关来处理业务逻辑，但这和跨AZ互通无关，在本机房访问物理云或托管云，也是需要经过它们各自的业务逻辑的网关的。只是在可用区逻辑下，我们大力整合了对各种不同