10 月 23 - 25 日,QCon 上海站即将召开,现在购票,享9折优惠 了解详情
写点什么

秒级容灾,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:531100

评论

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

真香!为什么设计行业流行部署云桌面?

青椒云云电脑

云桌面

定义现代化实时数据仓库,SelectDB 全新产品形态全面发布

SelectDB

数据库 大数据 数据湖 数据分析 云数据库

C4D在影视动画制作中的局限性

Finovy Cloud

C4D

大厂旗下的APP们成为自研大模型的“磨刀石”|TE洞察

TE智库

人工智能 BAT 大模型

代理价格监控和分布式价格监控有什么不同点?

巨量HTTP

http代理 分布式代理

【架构篇】Supabase的Postgrest组件架构介绍

张文平

数据库 postgresql 缓存 多表联查 Postgrest

人工智能:走向智能化生活

测吧(北京)科技有限公司

测试

软件测试 | 奇安信秋招面试题1

测吧(北京)科技有限公司

测试

软件测试 | 奇安信秋招面试题2

测吧(北京)科技有限公司

测试

Vue3中的Ref与Reactive:深入理解响应式编程

互联网工科生

前端框架 Vue 3

2023英特尔on技术创新大会:英特尔研究院展示多项技术“魔法”

E科讯

极光笔记 | 聊一聊推送系统中事件驱动架构的应用

极光GPTBots-极光推送

2024成都电子展|成都国际电子信息展览会

AIOTE智博会

电子信息展 成都电子展 电子信息博览会

英特尔研究院副总裁、英特尔中国研究院院长宋继强:英特尔技术为全行业带来卓越贡献

E科讯

你眼中的程序员 vs 程序员眼中的自己,是时候打破刻板印象了丨KubeCon 主题活动

阿里巴巴云原生

阿里云 容器 云原生 AIGC

《异构融合计算技术白皮书》正式发布,龙蜥助力新一代信息技术发展

OpenAnolis小助手

开源 白皮书 龙蜥社区 世界计算大会 异构融合计算

AI在生活中的惊人应用

测吧(北京)科技有限公司

测试

深度学习之“线下标注”

矩视智能

深度学习 机器视觉

开始报名!龙蜥社区走进 Arm MeetUp 议程硬核剧透来了

OpenAnolis小助手

开源 操作系统 arm Meetup 龙蜥社区

未来PC将是云电脑? 算力优势成为关键

青椒云云电脑

云电脑

RTC才是物联网企业的杀手锏!

X2Rtc

音视频 物联网 IoT RTC

人工智能 | ChatGPT账号注册

测吧(北京)科技有限公司

测试

AI带来的新创浪潮

测吧(北京)科技有限公司

测试

软件测试 | 奇安信秋招面试题3

测吧(北京)科技有限公司

测试

文心一言 VS 讯飞星火 VS chatgpt (101)-- 算法导论9.3 7题

福大大架构师每日一题

福大大架构师每日一题

流量治理的基石——基于字节码增强的全链路流量标签透传

华为云开源

微服务 微服务架构 字节码

【聚梦想 创非凡】2023荣耀开发者沙龙 ● 广州站 精彩回顾

荣耀开发者服务平台

互联网 用户增长 云服务 生态合作 行业经验

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