容器化RDS—— 计算存储分离 or 本地存储

最新推荐文章于 2024-07-13 13:42:26 发布
最新推荐文章于 2024-07-13 13:42:26 发布
阅读量276 收藏
点赞数
文章标签： 数据库 运维
本文探讨了在确保数据零丢失前提下，不同数据库架构的选择，包括计算存储分离与本地存储，并对比了MySQL Group Replication (MGR) 和 Percona XtraDB Cluster (PXC) 的性能。
摘要由CSDN通过智能技术生成


沃趣科技  熊中哲


随着交流机会的增多 (集中在金融行业 , 规模都在各自领域数一数二 ), 发现大家对 Docker + Kubernetes 的接受程度超乎想象 , 并极有兴趣将这套架构应用到 RDS 领域 . 数据库服务的需求可以简化为 :



实现数据零丢失的前提下,提供可接受的服务能力


因此存储架构的选型至关重要. 到底是选择计算存储分离还是本地存储?

本文就这个问题, 从以下几点展开 :

●     回顾 : 计算存储分离, 本地存储优缺点

●     MySQL 基于本地存储实现数据零丢失

●     性能对比

●     基于 Docker + Kubernetes 的实现


分享个人理解.

回顾 : 计算存储分离, 本地存储优缺点

还是从计算存储分离说起,

计算存储分离

先说优点 :

●     架构清晰

●     计算资源 / 存储资源独立扩展

●     提升实例密度, 优化硬件利用率

●     简化实例切换流程 : 将有状态的数据下沉到存储层, Scheduler 调度时, 无需感知计算节点的存储介质, 只需调度到满足计算资源要求的 Node, 数据库实例启动时, 只需在分布式文件系统挂载 mapping volume 即可. 可以显著的提高数据库实例的部署密度和计算资源利用率.

以 MySQL 为例

●     通用性更好, 同时适用于 Oracle , MySQL

       详见 : <容器化RDS : 计算存储分离架构下的"Split-Brain">

从部分用户的上下文来看, 存在如下客观缺点 :

●     引入分布式存储, 架构复杂度加大. 一旦涉及到分布式存储的问题, DBA 无法闭环解决.

●     分布式存储选型,

○     选择商用, 有 Storage Verdor Lock In 风险

○     选择开源, 大多数用户(包括沃趣)都测试过 GlusterFS 和 Ceph ,针对数据库(Sensitive Lantency)场景, 性能完全无法接受.

本地存储

如果在意计算存储分离架构中提到的缺点, 本地存储可以有效的打消类似顾虑,


无需引入分布式存储, 避免Storage Verdor Lock In 风险, 所有问题都由DBA 闭环解决,.


但是, 需要依赖数据库自有方案实现数据零丢失

以 MySQL 为例

还会引入类似问题,

●     物理容量受限于单机容量;

●     调度更复杂, 选定数据库实例的存储类型(比如 SSD )后, 一旦该实例发生”failover”, 只能调度到拥有 SSD 的物理节点, 这导致调度器需要对物理节点”Physical Topology Aware”;

●     密度难提升, 这是”Physical Topology Aware”的副作用;

●     因数据库的不同方案差异性较大, 通用性无法保证.

接下来, 进入正题, 看一下 MySQL 基于本地存储如何实现数据库零丢失.


MySQL 基于本地存储数据零丢失

最常用的是基于 Replication 模型将数据复制到 MySQL Cluster 中所有成员.

MySQL Master-Slave Replication (类似 Oracle DataGuard) 提供了基于 binlog 的数据库层的复制模型, 在高并发压力下节点间同步数据速率最快, 单位时间内的交易量受其他节点的影响极小, 该架构可通过 vip 漂移的方式实现 “failover”

MySQL Master-Slave Replication

但严格意义上来说, 这是基于 binlog 的 Asynchronous Replication 模型, 因此集群中所有成员存在数据不一致的可能,在”failover”时无法保证数据零丢失.

可见如果基于 Replication 模型, Synchronous Replication 是实现数据零丢失的前提.

传统的 Synchronous Replication 一般会采用两阶段提交或分布式锁, 这会带来如下几个问题 :

●     单位时间内事务能力(TPS) 会跟集群成员数量成反比

●     增加集群成员会显著且无法预期的增加事务响应时间

●     增加了集群成员数据复制的冲突和死锁的可能性

针对以上问题 Galera Cluster 提出 Certification-based Replication 来解决传统 Synchronous Replication 中遇到的问题, 实现如下 :

Deferred Update Replication 延迟更新复制

这个流程图中, 有几个细节需要分享,

●     将基于 binlog 改为基于 write-set. write-set 中包含修改的数据, Global Transaction ID (后面简称 GTID)和 Primary Key.

○     GTID 类似 45eec521-2f34-11e0-0800-2a36050b826b:94530586304

○     94530586304 为64-bit 有符号整型, 用来表示事务在序列中的位置

●     将传统的 Synchronous Replication 改为 Deferred Update Replication, 并将整个过程大致分解成四个阶段, 本地阶段, 发送阶段, 验证阶段和应用阶段, 其中 :

○     本地阶段 : 乐观执行, 在事务 Commit 前, 假设该 Transcation 在集群中复制时不会产生冲突

○     发送阶段 : 优化同步时间窗口, 除去全局排序并获取 GTID 为同步操作, 冲突验证和事务应用都为异步, 极大的优化了复制效率.

○     验证阶段 : 只有收到该事务的所有前置事务后(不能有 “hole”), 该事务和所有未执行的前置事务才能并发验证, 不然不能保证 Global Ordering, 因此这里需要牺牲效率, 引入一定的串行化.

      

需要等待事务3

于是就有了 Galera Cluster 在 MySQL 分支中的实现 MariaDB Galera Cluster (简称 MGC) 和 Percona Xtradb Cluster (简称 PXC)

为避免”split-brain”问题, 需要至少三节点组成集群, 对计算资源和存储资源的容量要求至少增加2倍, 会进一步降低资源的部署密度

越来越多的用户也期望通过该方案实现 跨 IDC 多活, 那么需要在规划阶段想清楚 :

     IDC 和 数据库节点的拓扑架构, 以保证在1个 IDC 出问题的情况, 集群可以持续提供服务

首先IDC (物理或逻辑) 最少需要3个, 再看看数据库节点数量分别为3, 4, 5, 6, 7的拓扑关系 :

●     3 数据库节点 :

●     4 数据库节点 :设置权重避免”split-brain” (? + ? ) + ? + ?

                         

●     5 数据库节点

●     6 数据库节点

●     7 数据库节点 : 可支持两种拓扑关系

同时, 还有 MySQL Group Replication[1] (简称 MGR), 类似 Galera Cluster :

●     基于Corosync实现(Totem协议), 插件式安装, MySQL 官方原生插件.

●     集群架构, 支持多写(建议单写)

●     允许少数节点故障, 同步延迟较小, 保证强一致, 数据零丢失

●     单位时间的交易量受 flow control 影响.

这里还需要提一下 Vitess[2]

●     该项目由 youtube 开源, 从文档看功能极为强大, 高度产品化.

●     作为第二个存储类项目(第一个是 Rook, 有意思是存储类而不是数据库类)加入 CNCF, 目前还处于孵化阶段(incubation-level).

●     笔者没有使用经验, 也不知道国内有哪些用户, 不做评论.

关于 MGR 和 Vitess 网上已有大量介绍, 这里不再赘述.

性能对比

在数据零丢失的前提下,  看看这几种架构在性能上的对比:

●     MGR 5.7.17 / PXC 5.7.14-26.17

●     MGR 5.7.17 / PXC 5.7.17-29.20 /  MariaDB 10.2.5 RC

●     本地存储 / 计算存储分离

性能对比1 : MGR 5.7.17 / PXC 5.7.14-26.17

测试背景描述 :

●     MGR 5.7.17  对比 PXC 5.7.14-26.17 (基于 Galera 3实现)

●     负载模型 : OLTP Read/Write (RW)

●     durability          : sync_binlog=1, innodb_flush_log_at_trx_commit=1

●     non-durability  : sync_binlog=0, innodb_flush_log_at_trx_commit=2

测试数据 : 

                            来自于 MySQL 官方[3]

测试结果 :

在设置 durability 的情况下,  MGR 最大吞吐约是PXC 5.7.14-26.17 (基于 Galera 3 实现) 的3倍, 优势明显.

以上数据来自于MySQL 官方, 公平起见, 再来看看 Percona 在相同负载模型下的测试数据.

性能对比2 : MGR 5.7.17 / PXC 5.7.17-29.20 /  MariaDB 10.2.5 RC

测试背景描述 :

●     增加了 MariaDB 参与对比

●     PXC 升级到 5.7.17-29.20, 该版本改进了MySQL write-set 复制层性能[4].

●     负载模型 : 依然使用 OLTP Read/Write (RW)

●     durability          : sync_binlog=1

●     non-durability  : sync_binlog=0

测试数据 :

设置 durability , 数据来自于 Percona[5]                

      

设置 non-durability , 数据来自于 Percona[6]  

测试结果 :

在负载模型相同的情况下(durability 和 non-durability) PXC 5.7.17-29.20 性能与 MGR 5.7.17 不分伯仲[7]. 如果使用 PXC, 推荐使用 5.7.17-29.20 或以上版本.

性能对比3 : 本地存储 / 计算存储分离

为了对比本地存储和计算存储分离, 专门使用 MGR + 本地存储架构 和 基于分布式存储的计算存储分离架构做性能对比.

测试结果 :

       在负载模型相同的情况下, 前者比后者 OLTP 下降32.12%, Select下降5.44%, Update下降24.18%, Insert 下降58.18%, Delete下降11.44%;

详细内容可留意 @波多野 同学 和 @韩杰 同学的测试报告, 这里不再赘述.

基于 Docker + Kubernetes 的实现

Docker + Kubernetes + MGR / Galera Cluster

在 github 上,可以看到基于 Docker + Kuberetes + PXC 的 demo[8]. 需要说明的是, 这仅仅是个玩具, 离部署到生产环境还有极大差距.

我们已有计划实现满足生产环境的

 

●     Docker + Kubernetes + PXC

●     Docker + Kubernetes + MGC

●     Docker + Kubernetes + MGR

并集成到 QFusion 来支持计算存储分离架构和本地存储架构混合部署, 架构示意图如下 :

 目前原型验证阶段已通过, 预计2018年Q2发布.

Docker + Kubernetes + Vitess

在 github 上,同样可以看到基于 Docker + Kubernetes 的 demo[9]. 有兴趣的同学可以玩一下.

性能只是选型需要考量的一部分, 要使用到生产环境或者产品化, 实际要考量的因素更多 :

●     运维 : 部署, 备份

●     弹性 : 计算存储扩容, 集群扩容

●     高可用 : 比如 “failover” 的细微差别对业务的影响

●     容错 : 比如网络对集群的影响, 尤其是在网络抖动或有明显延时的情况下

●     社区活跃度

●     …...

以现有软硬件的开放程度, 各种架构或者产品狭义上的”黑科技”并不多, 常常看到的

xxx 比 xxx 快 xxx 倍

严格来说应该是

xxx 比 xxx 在特定场景 xxx 下快 xxx 倍.

并不存在”一枪毙命”的”Silver Bullet”, 只是 Docker + Kubernetes 为混合部署带来可能. 哪种更受青睐, 拭目以待, 用户会是最好的老师.

<人月神话>中提到”No Silver Bullet.”, 原意是用来论述软件工程领域的生产力问题

由于软件的复杂性本质, 使得真正的银弹并不存在, 没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍.


[1] https://dev.mysql.com/doc/refman/5.7/en/group-replication-background.html


[2] http://vitess.io/

[3] http://mysqlhighavailability.com/performance-evaluation-mysql-5-7-group-replication/?spm=5176.100239.blogcont66550.17.T4N8cZ

[4] https://www.percona.com/blog/2017/04/19/performance-improvements-percona-xtradb-cluster-5-7-17/

[5] https://www.percona.com/blog/2017/04/19/performance-improvements-percona-xtradb-cluster-5-7-17/

[6] https://www.percona.com/blog/2017/04/19/performance-improvements-percona-xtradb-cluster-5-7-17/

[7] 因为没有看到 MariaDB 的官方数据, 公平起见, 不做评论.


[8] https://github.com/kubernetes/kubernetes/tree/master/examples/storage/mysql-galera

[9] https://github.com/kubernetes/kubernetes/tree/master/examples/storage/vitess

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/28218939/viewspace-2151448/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/28218939/viewspace-2151448/

congcheng1062
关注
云数据仓库的未来趋势：计算存储分离
阿里云云栖号
05-28 2113
简介：随着云时代的到来，数据库也开始拥抱云数据库时代，各类数据库系统在各内外云平台百花齐放，有开源的MySQL、PostgreSQL、MongoDB，传统数据库厂商的SQLServer、Oracle，云厂商自研的Aurora、Redshift、PolarDB、AnalyticDB、AzureSQL等。 作者 | 尚春 来源 | 阿里技术公众号 一 背景 随着云时代的到来，数据库也开始拥抱云数据库时代，各类数据库系统（OLTP、OLAP、NoSQL等）在各内外云平台（AWS、Azure、阿里云）百.
聊聊计算和存储分离
热门推荐
lizhao007
02-03 1万+
1.背景 这篇文章是我一直想写的一篇，因为“计算和存储分离”最近几年在大家的视野中出现得越来越多，但其实很多对于其到底代表着什么也是模糊不清，这里我查阅了很多的资料再结合平时自己的理解，...
存储计算分离
yilan1993的专栏
08-08 347
一句话：学术界往往要比工业界提前，就像google永远比其他公司提前一样。 在本人的硕士毕设中，标题是“面向存储计算分离的云化大规模数据库缓存系统”，故整理如下内容。 其实早在2009年，就有人提出针对Hadoop提出了SuperDataNode的概念，提出了计算分离的想法。具体请参考论文。往往学术界要比工业界提前好几年，等到真正技术...
存算分离（Separation of Storage and Computation）
最新发布
2301_77836489的博客
07-13 517
存算分离（Separation of Storage and Computation）
存储与计算的分离
herofour444的专栏
08-01 8786
存储与计算的分离马一力　傅湘林　韩晓明　许鲁 1   存储应用的新特性 　　IT技术的发展经历过三次浪潮：第一次浪潮以计算技术为中心，以处理器的发展为核心动力，产生了计算机工业，推动了计算机的迅速普及和应用；第二次浪潮以传输技术为中心，促进了计算机网络的发展和普及。这两次浪潮大大加速了信息数字化进程，使得越来越多的人类信息活动转变为数字形式，从而导致数字化信息爆炸性增长，进而引发IT技术
容器化RDS：计算存储分离还是本地存储？
woqutechteam的博客
03-02 859
沃趣科技  熊中哲随着交流机会的增多（集中在金融行业，规模都在各自领域数一数二），发现大家对 Docker + Kubernetes 的接受程度超乎想象, 并极有兴趣将这套架构应用到 RDS 领域。数据库服务的需求可以简化为：实现数据零丢失的前提下，提供可接受的服务能力。因此存储架构的选型至关重要。到底是选择计算存储分离还是本地存储？本文就这个问题，从以下几点展开：回顾：计算存储分离, 本地存储优...
容器化RDS｜计算存储分离架构下的IO优化
CSDN研发技术
01-10 3901
在基于 Kubernetes 和 Docker 构建的私有 RDS 中，普遍采用了计算存储分离架构。该架构优势明显， 但对于数据库类 Latency Sensitive 应用而言，IO 性能问题无法回避，下面分享一下我们针对 MySQL 做的优化以及优化后的收益。 计算存储分离架构 架构示意图如下： 存储层由分布式文件系统组成，以 Provisoner 的方式集成到 Kuberne
容器化RDS｜计算存储分离架构下的 IO 优化
woqutechteam的博客
01-12 311
作者：沃趣科技联合创始人 熊中哲 在基于 Kubernetes 和 Docker 构建的私有 RDS 中，普遍采用了计算存储分离架构。该架构优势明显， 但对于数据库类 Latency Sensitive 应用而言，IO 性能问题无法回避，下面分享一下我们针对 MySQL 做的优化以及优化后的收益。 计算存储分离架构 架构示意图如
阿里云RDS——产品系列概述
aliyunduoduo的博客
11-28 1894
云数据库RDS的产品系列包括基础版、高可用版、集群版、三节点企业版，本文介绍基础版实例的相关信息。RDS基础版实例也称为单机版实例，只有单个数据库节点，计算与存储分离，性价比超高。说明 RDS基础版实例只有一个数据库节点，没有备节点作为热备份，因此当该节点意外宕机或者执行重启实例、变更配置、版本升级等任务时，会出现较长时间的不可用。如果业务对数据库的可用性要求较高，不建议使用基础版实例，可选择其他系列（如高可用版），部分基础版实例也支持。基础版与高可用版的对比拓扑图如下所示。优势性能。
DSP中的DC/DC转换器数据表——计算系统损耗
10-16
漏-源通道电阻(RDSON)产生的功率耗散可以用公式1表示：  对于LM2673这样的非同步设备，在集成MOSFET关闭时，二极管被正向偏置。在此期间，电感电流通过输出电容器、负载和正向偏置二极管降低。负载...
5G科普——计算与存储分离
帆_5021的博客
03-18 1770
计算与存储分离可使5G更健壮更稳定！ 在移动通信网络中计算和存储体现在终端用户的处理上，计算表示对用户信息的运算和分发；存储表示对用户信息的存放。在4G时代，核心网的数据分为两大类，一类是用户签约信息，与用户信息身份对应，单独存储在后端数据库中，我们称这类数据为结构化数据；另一类是用户会话信息，跟随核心网业务网元进行业务处理而产生的，并进行本地化存储，这些业务网元除了负责进行业务处理外还承担会...
简单了解存算分离
铁打的键盘也能敲出优雅的生活
12-09 3220
简单了解存算分离
什么是存储计算分离架构？
weixin_39666736的博客
01-21 3672
1.背景 首先我们谈谈Hadoop的背景，说到Hadoop起源，就离不开Google的三辆马车：Google File System、MapReduce和BigTable，分别说了分布式文件系统、分布式计算MR和分布式结构化存储系统 MapReduce论文翻译：MR链接 Google file system论文翻译：gfs链接 bigtable论文翻译：bigtabel链接 Hadoop从2005年提出，采用的是存储计算耦合的架构，Hadoop将所有的计算（如：mapreduce、spark）和存储（如
容器化RDS｜计算存储分离架构下的“Split-Brain”
woqutechteam的博客
02-26 592
不管是架构选型还是生活，大多数时候都是在做trade off，获了计算存储分离带来的好处, 也意味着要忍受它带来的一些棘手问题。本文尝试结合Kubernetes，Docker，MySQL和计算存储分离架构，分享我们遇到的诸多问题之一 “Split-Brain” 。2018年1月19号参加了阿里巴巴双十一数据库技术峰会，见到了好多老同事（各位研究员、资深专家），也了解到业界最新的数据库技术发展趋势：...
存算分离数据架构
Oo_Amy_oO的博客
12-19 1318
在传统的架构中，存储和计算通常是紧密耦合的，数据必须从存储系统中读取到计算节点进行处理。在这个存算分离架构中，数据的存储和计算被解耦，可以灵活地进行扩展和优化。总结： 搭建存算分离数据架构需要设计存储层和计算层的架构，进行数据同步和导入，将计算和存储分离，设计数据访问接口，并进行监控和优化。计算和存储分离：将计算过程从存储层分离出来，将计算结果存储到独立的计算数据层中。数据同步和导入：将持久化数据从存储层导入到计算层，可以使用ETL工具或者自定义数据同步脚本进行数据导入，保证计算层能够及时获取最新的数据。
解构“存算分离”
Chengz77_的博客
06-16 996
这样做的好处也是显而易见的，首先是可以实现计算和存储资源的单独扩容，然后原本分散的数据 实现集中存储，打造统一数据湖。不管我们承认与否，其实是网络一直在制约基础IT架构的演进和发展，过去由于网络带宽的限制， 我们习惯性的把计算和存储偶合在一起，以减少网络传输的压力，比较典型的就是MapReduce和 Hadoop，就是用本地IO代替网络传输，是计算和存储耦合在一起的典型场景。：作为底层的资源平台，基础IT环境的资源总是有限的，站在业务的角度是计算先达到瓶颈，还是存储先达到瓶颈，他们的时间点是不一样的。
在大数据领域，如何实现存储计算分离？
分享Java技术知识，共同成长进步！
09-15 688
导读 在过去十几年的发展中，HDFS以其高容错性、高吞吐量等特性，成为分布式大数据体系的核心组件，稳坐分布式大数据存储的第一把交椅。随着各行各业对大数据技术的利用率提升，在面对不断扩张的大数据集群规模、不断增长大数据存储量级时，原生的HDFS架构设计在支撑能力上显露不足。虽然社区提出了Federation等概念，但依旧无法解决因单点元数据暴增带来的NameNode GC压力、DataNode的心跳汇报风暴等问题。此外对于海量小文件的处理一直也是HDFS的短板。因此，Apache Ozone应运而生。
大数据上云存算分离演进思考与实践
阿里技术
03-28 3096
本文将从大数据产品商业化从业者的视角来探讨与分析大数据领域的存算分离演进过程，核心价值，与相关所产生的蓬勃技术生态。
mysql 计算 存储分离_MySQL存储计算分离实践
weixin_36248747的博客
01-19 212
MySQL数据库的配置文件“my.cnf”，请参考以下主要介绍“LD_PRELOAD”高性能的使用方法，其它使用方式请参考“快速入门“栏目中的#初始化MySQL数据库。#DBFS_HOME的中值，通过dbfs_get_home_path.sh fsid得到，其中fsid为“db8acoqte8r9”，以下类同。DBFS_HOME="/opt/dbfs/data/44a2444a-9c11-4612...
华为云RDS for Mysql是否是存储计算分离的架构
07-08
是的，华为云RDS for MySQL也采用了存储计算分离的架构。类似于阿里云RDS for MySQL，华为云RDS for MySQL将存储和计算功能分离，通过不同的服务器来处理这两个方面的任务。这种架构可以提高数据库的性能、可伸缩性和可靠性，同时也能够更好地隔离存储和计算资源，提高系统的稳定性和安全性。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值