快节奏的生活，任何的业务异常/中断都是不能容忍的。
在无人化超市选购完成进行结账时，结账页面突然卡住，无法完成购买操作。这时该选择放弃手中的商品or继续等待？
酒店办理入住时，管理系统突然崩溃，无法查询预订记录，导致办理入住受到影响，酒店前台排起了长队……
高可用与我们每个人都是息息相关的，在即将到来的双十一，更是对各个电商的业务可用性提出了更高的要求。对此，UCloud提供基于内网VIP的高可用服务，内网VIP通过前后三代广播集群的设计演进，解决了复杂异构Overlay网络下的广播实现问题，获得秒级高可用切换能力，并能够很好的支持物理云。
下面，本文将对UCloud秒级切换的内网高可用服务进行详细介绍。
基于内网VIP的高可用服务
1、高可用的理念和要点
从业务角度看，当然要尽可能避免应用出现故障。但要完全不出故障是不可能的。
那如何解决这个问题呢？答案就是相信任何单一节点都不可靠，要为每个节点增加备份。当任一节点发生故障时，业务自动切换至正常节点，且整个切换过程用户均无感知，这就是高可用的基本理念。而实现高可用的两个要点是备份节点和自动故障转移。
图：一旦A发生故障，便会迅速切换至B
2、传统网络的高可用方案
在传统网络中，Keepalived+虚拟IP是一个经典的高可用解决方案。
Keepalived是基于VRRP协议的一款高可用软件，有一台主服务节点和多台备份节点，并部署相同的服务。主节点对外使用一个虚拟IP提供服务，当主节点出现故障时，Keepalived发起基于VRRP的协商，选择备节点升级为主节点，虚拟IP地址会自动漂移至该节点，同时利用GARP宣告虚拟IP的位置信息更新，从而保证服务正常。
3、云计算Overlay网络下的高可用
云计算下的网络架构发生了巨大变化，传统的网络架构已经更新为Overlay网络，并出现了各类复杂的异构网络。那么在新的网络环境下，该如何解决高可用这个问题呢？
首先我们看一下云计算网络的基本原理：
图：云计算网络的实现
如上图，云资源都桥接在OVS的网桥上，同时业务网卡也桥接在OVS的网桥上，Controller为UCloud基于开源框架Ryu自研实现。Controller通过与后台Manager的交互，拉取ACL、路由表、VPC联通、隔离等各类信息，并通过OVS Message将Flow固化在OVS的网桥上，达到Flow管理的目的，实现ACL的联通与阻断、三层转发的功能，进而完成VPC联通及租户隔离的能力。上层的实际业务报文，通过GRE封装，对下层网络保证透明。
鉴于用户在云计算网络中实现高可用的复杂性，UCloud设计了内网VIP产品，为云平台上的云主机、物理云主机提供服务。作为用户自定义高可用服务的可漂移内网入口，从发现故障到自动完成故障切换，无需额外的API调用和机器内部配置，即可完成秒级切换。
图：内网VIP控制台操作界面
内网VIP如何实现故障转移的秒级切换？
内网VIP的故障切换时长通常与以下两个步骤相关：
1、Master发生故障后，备服务器需要选举出新的Master；
2、需要在广播域内告知其他节点，该IP的位置发生了变化。
如上文所述，在Overlay网络中，上层业务报文的ARP协议解析、IP寻址、单播、多播、广播都需要重新实现，会有不小难度。那么广播应当如何实现呢？
UCloud基于广播的实现机制，演进出了如下的三个版本。
第一代：模拟广播
图：模拟广播
如上图所示，一个广播报文直接复制N份，送到其他广播域中的节点，即可完成广播的行为。由于OVS支持报文的复制和传输，只需要在Flow中指定多个Output动作即可实现。Flow的模式如下：
图：模拟广播中Flow模式
这种实现确实可以满足需求，但是存在几个明显的缺点：
1、Flow的更新。由于用户的广播域是变化的，一旦广播域发生变化，那么所有广播域中节点所在宿主机上的广播Flow全部需要推送更新。因此如果用户的广播域比较大，这种更新非常消耗性能。
2.、Flow的长度数量有限制。OVS对Flow的长度有要求：单条Flow的长度不能超过64K bit，而广播域增加的时候，Flow的长度一定随之增长。如果客户的子网比较大，导致超过了Flow的长度限制，那么就无法再进行更新，出现广播行为异常，进而影响高可用实现。
3、异构网络的广播需要单独实现。比如物理云主机底层不是基于OVS的架构，那么就必须重现一遍，开发和维护成本很高。
为解决上述问题，UCloud开发出了第二代广播解决方案——广播集群：
第二代：广播集群
图：广播集群
如上图，所有的广播流量通过Flow指向自研的广播集群。广播集群从业务数据库中拉取广播的信息，对报文进行复制和分发。广播集群是UCloud基于DPDK自研的高可用集群，可以高性能地实现广播逻辑。
采用广播集群，我们很好的解决了第一代广播逻辑中存在的问题：
1、广播域的变化问题。广播域变化只需要通知广播集群即可，无需全网告知。
2、广播域的大小问题。广播集群通过DPDK来进行报文的复制和转发，理论上广播域无上限。
3、各种网络的适配问题。各类网络只需要将广播报文送到广播集群即可，无需进行额外的逻辑开发，很好的适配了各种网络场景。
随后，在第二代的基础上，UCloud又提供了第三代的广播解决方案：
第三代：广播集群+GARP嗅探
图：基于GARP嗅探的广播集群
在第二代广播集群已经可以很好的实现高可用服务的情况下，UCloud为什么还要开发出第三代呢？
从前文我们可以知道，在VIP切换的过程中，GARP将利用广播告知整个广播域，进而VIP发生漂移。但是广播域之外的服务器是没有能力获知相关信息的。这样就会出现下列问题：VIP的切换会导致跨三层的访问失效。
而跨三层的访问则要求后台数据库必须通过某种方式获知VIP位置的变化。在内网VIP的切换过程中，GARP报文会通知广播域内的节点VIP的位置信息变化，而广播集群可以获取到所有的广播流量。因此，广播集群利用ARP_SPA=ARP_TPA的特征过滤得到GARP流量，将相应的位置信息上报到后台，并更新Flow信息，从而保证三层的访问正常。
在第三代架构下，广播集群对公有云、物理云等多种异构网络均进行了支持，满足不同云计算高可用应用场景的需求。
应用实例解析
1、电商支付系统高可用实践
某电商在频繁的日常消费与各类促销活动中对支付系统可用性提出了很高的要求。消费者对支付系统的可用性是非常敏感的，一旦出现任何一点小小的故障，诸如“付款失败、重新支付、支付超时”等都会带来不好的使用体验，严重时甚至可能导致用户流失。
在不考虑外部依赖系统突发故障的前提下，如网络问题、第三方支付和银行的大面积不可用等情况，该电商希望通过提高自身支付系统的高可靠服务能力来保证消费者的可用性体验。
为了实现高可用，UCloud基于Keepalived+内网VIP产品为该电商线上支付系统快速构建了高可靠服务，从而避免自身单点故障，大大提高系统的可用性。
图：高可用服务构建实例
如上图，VIP绑定在UPHost(物理云主机)作为主节点存在，当VIP绑定的Master节点发生故障的时，便会发生VIP漂移。物理云网关收到GARP报文，并将GARP报文送至广播集群。广播集群分析GARP报文后，会将位置上报到后端，并更新物理云网关配置和公有云平台的Flow。随后，广播集群复制GARP报文，并发送到广播域内的所有UHost和UPHost。二层访问的信息和三层访问的信息都会在秒级内得到更新，保证业务的高可用。
2、UCloud云数据UDB产品高可用技术实现
在UCloud云数据UDB产品的高可用技术实现中，也同样应用了内网VIP技术。如下图，UDB产品采用双主架构，并通过Semi-Sync实现数据同步，由UDB可用性管理模块实时监控底层节点可用性，一旦监测到Master DB不可用，便会自动触发容灾切换机制，内网VIP无状态漂移至Standby DB，保证用户UDB数据库服务的稳定可靠。
图：基于内网VIP的UCloud 高可用DB技术实现
在UDB高可用实现的过程中，由于采用单一内网VIP接入，因此可以完成应用层的无缝切换，整个过程中无需用户进行任何人工干预和配置修改。依托内网VIP，UDB产品为用户提供了高可用的数据库服务，目前该产品已经服务于上万家企业并提供了数万份数据库实例。
结语
高可用是一个复杂的命题，除了应用内网VIP产品规避可能出现的单点故障外，还需要在服务维护方面做到严格规范操作，包括事前做好服务分割，事后做好服务监控等。
但仅止于此吗？墨菲定律告诉我们：凡是可能出错的事有很大几率会出错。每日三省吾身：业务架构是否足够稳定？异常处理是否足够完备？灾备方案是否足够充分？并据此不断优化业务系统，祝愿每个运维工程师都可以睡个好觉！
340
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
