容器化RDS|计算存储分离架构下的IO优化

在基于 Kubernetes 和 Docker 构建的私有 RDS 中,普遍采用了计算存储分离架构。该架构优势明显, 但对于数据库类 Latency Sensitive 应用而言,IO 性能问题无法回避,下面分享一下我们针对 MySQL 做的优化以及优化后的收益。

计算存储分离架构

架构示意图如下:

存储层由分布式文件系统组成,以 Provisoner 的方式集成到 Kubernetes。

在我们看来,计算存储分离的最大优势在于:

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

其他的好处还有很多,譬如架构更清晰,扩展更方便,问题定位更简单等,这里不赘述。

计算存储分离架构的缺点

俗话说的好:

上帝为你关上一扇窗的同时,再关上一扇门。

如下图所示:

相较本地存储, 网络开销会成为 IO 开销的一部分, 我们认为会带来两个很明显的问题:

  • 数据库是 Latency Sensitive 型应用, 网络延时会极大影响数据库能力(QPS,TPS);
  • 在高密度部署的场景, 网络带宽会成为瓶颈, 可能导致计算 & 存储资源利用不充分。

其实还有一个极其重要的问题,由于kubernetes 本身没有提供 Voting 服务和类似 Oracle Rac 的 Fence 机制,在计算存储分离架构下,当集群发生脑裂,并触发 Node Controller 和 Kubelet 的驱逐机制时,可能会出现多个数据库实例同时访问一份数据文件导致 Data Corruption 的情况,数据的损失对用户而言是不可估量也不可忍受的。我们在 kubernetes 1.7.8 下使用 Oracle,MySQL 都可以100%复现这个场景,通过在 Kubernetes 上添加 Fence 机制,我们已解决该问题。如果大家有兴趣,会再做专门的分享。

下面,就需要结合 MySQL 的特性来进行有针对性的优化。

以下测试方案的设计,测试数据的梳理来自于沃趣科技MySQL专家@董大爷 和 @波多野老师。

DoubleWrite

在 MySQL 中我们首先想到了 DoubleWrite。首先看下官方解释,它是干什么的:

The InnoDB doublewrite buffer was implemented to recover from half-written pages. This can happen when there’s a power failure while InnoDB is writing a page to disk. On reading that page, InnoDB can discover the corruption from the mismatch of the page checksum. However, in order to recover, an intact copy of the page would be needed. The double write buffer provides such a copy. Whenever InnoDB flushes a page to disk, it is first written to the double write buffer. Only when the buffer is safely flushed to disk will InnoDB write the page to the final destination. When recovering, InnoDB scans the double write buffer and for each valid page in the buffer checks if the page in the data file is valid too. Although data is written twice, the doublewrite buffer does not require twice as much I/O, as data is written to the buffer in a large sequential chunk with a single fsync() call. There is extra time consumed however, and the effect becomes visible with fast storage and a heavy write load.

简单说 DoubleWrite 的实现是防止数据页写入时发生故障导致页损坏(partial write),所以每次写数据文件时都要将一份数据写到共享表空间中,当启动时发现数据页 Checkum 校验不正确时会使用共享表空间中副本进行恢复,从 DoubleWrite 实现来看这部分会产生一定量的 IO。所以:

最好的优化就是减少 IO,在底层存储介质或文件系统支持 Atomic Write的前提下,可以关闭 MySQL 的 DoubleWrite 以减少 IO。

单机架构:关闭 DoubleWrite

MariaDB 已支持该功能(底层存储介质需支持 Atomic Write ),并在单机环境做了相关测试。数据如下:

结论:单机环境下,启用Atomic Write(关闭 DoubleWrite )能立即带来30%左右的写性能改善。

原文地址:http://blog.mariadb.org/mariadb-introduces-atomic-writes/

计算存储分离架构:关闭 DoubleWrite

所以,重点是我们需要测试一下在计算存储分离架构下(分布式存储必须支持 Atomic Write ),关闭 DoubleWrite Buffer 的收益。

测试场景

  • 采用Sysbench 模拟 OLTP 敷在模型 (跟 MariaDB 相同)
  • 数据库版本选择了更流行的 MySQL 5.7.19 (测试时的最新版本)
  • 由本地存储改为分布式文件系统
  • 测试数据量, 数据文件大写 1、10GB 2、100GB

测试结果:10GB数据量

Sysbench 指标

指标类型

线程个数

表数量

数据量

测试时长(分钟)

平均tps

平均qps

响应时间(95%)

oltp开双写

256

8

500W

10

5632

112643

73.13 ms

oltp关双写

256

8

500W

10

5647

112959

86.00 ms

分布式文件系统指标

在计算存储分离架构下,启用Atomic Write(关闭 DoubleWrite ),10GB数据量,因为大部分数据已经缓存到数据库 buffer cache 中,所以在 IO 不是瓶颈的情况下

  • Sysbench指标, 提升不明显
    • tps ↑0.2656%,qps ↑0.2797%,rst ↑14.9651%
  • 分布式文件系统指标
    • Throughput 下降53%, 显著优化了网络带宽

测试结果:100GB数据量

Sysbench 指标

指标类型

线程个数

表数量

数据量

测试时长(分钟)

平均tps

平均qps

响应时间(95%)

oltp开双写

256

8

500W

10

2260

45202

227.40 ms

oltp关双写

256

8

500W

10

2519

50394

277.21 ms

分布式文件系统指标

在计算存储分离架构下, 启用Atomic Write(关闭 DoubleWrite ),100GB数据量, 因为大部分数据无法缓存到数据库 buffer cache 中,所以在 IO 是瓶颈的情况下

  • Sysbench指标, 提升明显:
    • TPS ↑28.0892%,QPS ↑28.0893%,RST ↓169.2033%
  • 分布式文件系统指标
    • IOPS 提升22.3%
    • Latency 下降 39%
    • 在IOPS 提升22.3%的情况下,Throughput 仅多消耗 3.6%

总结

想让数据库安全,高效的运行到 Kubernetes 和 Docker 的架构下并不容易,本文分享的只是众多问题之一,任重而道远……想在上面持续发力的同学,自求多福吧!

原文发布于微信公众号 - CSDN技术头条(CSDN_Tech)

原文发表时间:2018-01-12

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏杨建荣的学习笔记

快速定位隐蔽的sql性能问题及调优(r5笔记第38天)

在前几天,有个开发同事问我一个问题,其实也算是技术救援,他说在有个job数据处理的频率比较高,在测试环境中很难定位出在哪有问题,而且速度也还能接受,但是在生产环...

37660
来自专栏BeJavaGod

网站平台架构演变史(三) - 数据库表的查询优化

上篇说道了数据库读写分离,对于大型网站来说这么说是十分有必要的。数据库在整个互联网架构中担当的角色无法有两个,存储和运算,很多时候这两个是并存的,但是在后期,对...

39870
来自专栏大数据和云计算技术

大数据和云计算技术周报(第38期):NoSQL特辑

本期有 HBase入门教程、Spark On HBASE、HBase二级索引、SQL 与 NoSQL、高并发&高可用、MySQL索引、Redis。 希望大家会喜...

10510
来自专栏Java进阶干货

三思!大规模MySQL运维陷阱之基于MyCat的伪分布式架构

分布式数据库,已经进入了全面快速发展阶段,这种发展,是与时俱进的,与人的需求是分不开的,因为现在信息时代的高速发展,导致数据量和交易量越来越大。这种现象首先导致...

62310
来自专栏TEG云端专业号的专栏

伸手党福利 - 直击TFS技术内幕

TFS平台提供以文件为粒度的上传,下载,删除等数据访问服务,系统分为接入,文件索引,索引存储,数据存储四个部分。

90440
来自专栏杨建荣的学习笔记

数据迁移中需要考虑的问题(r2第15天)

在生产环境中,做数据迁移需要考虑很多的可能性和场景,尽量排除可能发生的问题。我自己总结了下,大体有如下需要注意的地方。 1)充分的测试,评估时间,总结经验,提升...

32190
来自专栏后端技术探索

淘宝高并发订单的数据库方案

周末参加了@淘宝技术嘉年华 主办的技术沙龙, 感觉收获颇丰,非常感谢淘宝人的分享。这里我把淘宝下单高并发解决方案的个人理解分享一下。我不是淘宝技术人员,本文只是...

34020
来自专栏双十二技术哥

Android性能优化(八)之网络优化

移动互联网发展到现在,用户的联网方式已经完成了由流量依赖到Wifi依赖的转变。虽然网络环境在变好,但也对网络的应用提出了更高的要求,同时开发人员对网络的重视度却...

21430
来自专栏施炯的IoT开发专栏

Microsoft IoT Starter Kit 开发初体验

1. 引子     今年6月底,在上海举办的中国国际物联网大会上,微软中国面向中国物联网社区推出了Microsoft IoT Starter Kit ,并且免费...

282100
来自专栏编程一生

美团点评智能支付核心交易系统的可用性实践

15310

扫码关注云+社区

领取腾讯云代金券