写点什么

秒级容灾,UCloud 内网高可用服务之三代架构演进

  • 2019-11-07
  • 本文字数:3463 字

    阅读完需:约 11 分钟

秒级容灾,UCloud内网高可用服务之三代架构演进

快节奏的生活,任何的业务异常/中断都是不能容忍的。


在无人化超市选购完成进行结账时,结账页面突然卡住,无法完成购买操作。这时该选择放弃手中的商品 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 产品规避可能出现的单点故障外,还需要在服务维护方面做到严格规范操作,包括事前做好服务分割,事后做好服务监控等。


但仅止于此吗?墨菲定律告诉我们:凡是可能出错的事有很大几率会出错。每日三省吾身:业务架构是否足够稳定?异常处理是否足够完备?灾备方案是否足够充分?并据此不断优化业务系统,祝愿每个运维工程师都可以睡个好觉!


本文转载自公众号 UCloud 技术(ID:ucloud_tech)。


原文链接:


https://mp.weixin.qq.com/s/tqWGCr3Id5tpklNPNy_XUg


2019-11-07 22:53898

评论

发布
暂无评论
发现更多内容

架构之:微服务和单体服务之争

程序那些事

微服务 系统架构 软件架构 程序那些事

JavaScript数组详解-全网最全

二郎神杨戬

7月日更

聚星公社软件开发|聚星公社APP系统开发

BHDEX币挖矿APP系统开发内容

项目经理的职责和权限分别是什么?

万事ONES

项目管理 ONES 项目经理

Vue.js+ElementUI+vant生成动态表单配置

二郎神杨戬

7月日更

UD众筹链/UD生态系统APP开发详情

如何给MindSpore添加一个新的硬件后端?快速构建测试环境!

华为云开发者联盟

AI 模型 框架 mindspore

如何做需求分析?

万事ONES

产品经理 需求分析 ONES

JAVA 九种排序算法详解(中)

加百利

Java 数组 排序 7月日更

真happy软件开发|真happy系统APP开发

Redisson 分布式锁源码 03:可重入锁互斥

程序员小航

redis 源码 分布式锁 redisson

联想科技产业行——大众集团走进联想:智慧科技赋能汽车行业智能化变革

科技大数据

科技互联网 新未来 联想

社交软件上“你可能认识的人”到底是怎么找到你的?

华为云开发者联盟

知识图谱 社交软件 TransE模型 用户画像 知识图谱补全

Camtasia实用技巧之智能聚焦

淋雨

视频剪辑 Camtasia 专业录屏

2022秋招vue面试题+答案

buchila11

Vue Vue 3

根据舌苔判断身体状况

kof11321

快看吧系统开发|快看吧软件APP开发

【Flutter 专题】96 图解 Draggable + DragTarget 基本拖拽效果

阿策小和尚

Flutter 小菜 0 基础学习 Flutter Android 小菜鸟 7月日更

Rust从0到1-Cargo-发布到Crates.io

rust 发布 cargo crates.io publish

富文本编辑器之游戏角色升级ing

vivo互联网技术

Java 大前端 富文本 富文本编辑器

IPC阿波罗公链软件系统开发搭建

@Autowired报错原因分析和4种解决方案!

王磊

Java spring springboot @Autowired注入原理 Autowired

Go 学习笔记之 整型数据类型

架构精进之路

Go 语言 7月日更

北鲲云超算平台——致力于提高科研效率,降低计算成本的云超算平台

北鲲云

一条SQL语句执行的背后

卢卡多多

log sql 更新 执行顺序 7月日更

海洋之星系统开发|海洋之星软件APP开发

XRP瑞波币系统开发|XRP瑞波币软件APP开发

多标签分类中的损失函数与评价指标

月来客栈

PyTorch 多标签 多标签分类 文本分类

微摩尔WMO软件系统开发介绍

GIN钱包挖矿系统开发|GIN钱包挖矿软件APP开发

秒级容灾,UCloud内网高可用服务之三代架构演进_文化 & 方法_内网VIP产品团队_InfoQ精选文章