异地机房容灾解决方案.docx

异地机房容灾解决方案在本系列的第一篇文章里（解密「云计算的太祖长拳」系列之一“胆”：基础网络改造与新架构），我们详细介绍了为了支持可用区新功能，UCloud在基础网络建设和外网特性方面所做的一系列改造，其中包括基础网络的双星型拓扑结构和POP点的建设；EIP、ULB、以及共享带宽的功能跨AZ的使用；跨AZ流量调度的核心模块 - UVER (UCloud Virtual Edge Router)的实现等方面的内容。本篇文章是该系列的第二篇，我们会着重介绍在可用区研发过程中，我们对UCloud公有云平台的底层SDN架构所做的一系列改造。这些改造有的是宏观层面的重构和演进，有的看似是局部的调整但实则是在亲历了运营一个大型IaaS平台所遇到的那些困难之后才审慎提出的一套解决方案。Agenda:SDN底层架构重构支持虚拟网络广播协议带来的架构变化SDN封装隧道与流表的优化结语SDN底层架构重构（网元跨可用区的互访）UCloudIaaS平台上支持多种不同类型的计算节点，比如公有云上的虚拟主机（我们简称“公有云”），物理主机（简称“物理云”），以及托管区域的主机（简称“托管云”）等等。这些节点或者说网元在底层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互通无关，在本机房访问物理云或托管云，也是需要经过它们各自的业务逻辑的网关的。只是在可用区逻辑下，我们大力整合了对各种不同类型网元间互访的支持，使得同一个Region下，不同类型网元的互访成为默认支持的模式而无需进过特别的协调或非标操作：支持虚拟网络广播协议带来的架构变化上文提到，利用可用区的特性，用户虚拟网络“大二层”的范围事实上已经扩展到整个Region所有的AZ里了。由此带来的特性能力之前已经有了诸多阐述，但同时，也有很多基础架构层面上的挑战随之而来。在这里我们着重对于在虚拟网络中支持广播协议这一场景做一些深入的探究。众多的公有云平台在其虚拟网络中是不