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

原创 2018年01月10日 16:37:29

在基于 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 的架构下并不容易,本文分享的只是众多问题之一,任重而道远……想在上面持续发力的同学,自求多福吧!

作者:熊中哲,沃趣科技。


1月13日,SDCC 2017之数据库线上峰会即将强势来袭,秉承干货实料(案例)的内容原则,邀请了来自阿里巴巴腾讯微博网易等多家企业的数据库专家及高校研究学者,围绕Oracle、MySQL、PostgreSQL、Redis等热点数据库技术展开,从核心技术的深挖到高可用实践的剖析,打造精华压缩式分享,举一反三,思辨互搏,报名及更多详情可点击此处查看。

图片描述

版权声明:本文为博主原创文章,未经博主允许不得转载。

计算机系统的硬件结构之存储器

一、存储器概述 1.存储器分类 2.存储器的层次结构 二、主存储器(内存) 1.主存储器概述 2.半导体存储芯片 3.随机存取存储器 4.只读存储器 5.存储器与CPU的连接 6.存储器的校验 7.提...
  • u012481172
  • u012481172
  • 2015年10月29日 23:34
  • 1367

RDS MySQL空间优化最佳实践

在前三期介绍了RDS for MySQL参数优化,锁问题以及延迟优化最佳实践之后,本期将介绍存储空间相关的最佳实践。...
  • Mini_Monster
  • Mini_Monster
  • 2016年07月09日 10:01
  • 1323

网站架构(页面静态化,图片服务器分离,负载均衡)方案全解析

1、HTML静态化其实大家都知道,效率最高、消耗最小的就是纯静态化的html页面,所以我们尽可能使我们的网站上的页面采用静态页面来实现,这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更...
  • OnlyOneCoder
  • OnlyOneCoder
  • 2013年02月05日 15:30
  • 4580

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

作者:熊中哲(沃趣科技)邮箱:orain.xiong@woqutech.com,欢迎交流~在基于 Kubernetes 和 Docker 构建的私有 RDS 中,普遍采用了计算存储分离架构。该架构优势...
  • n88Lpo
  • n88Lpo
  • 2018年01月11日 00:00
  • 60

干货|现代IM系统中消息推送和存储架构的实现

摘要:前言 IM全称是『Instant Messaging』,中文名是即时通讯。在这个高度信息化的移动互联网时代,生活中IM类产品已经成为必备品,比较有名的如钉钉、微信、QQ等以IM为核心功能的产品。...
  • ax8785r8C32nef593
  • ax8785r8C32nef593
  • 2017年12月05日 00:00
  • 345

案例|服务化架构系统监控难题解决方案

原文网址链接:http://url.cn/kVjUVO 众所周知,系统监控一直是拥有复杂IT架构的企业所面临的一个重要问题,而这也并不是每家企业都能够轻松解决的技术挑战。OPPO作为一家国际智能终端...
  • aeaiesb
  • aeaiesb
  • 2015年11月02日 09:53
  • 1023

光音网络的存储容器化方案探索

  • 2017年07月11日 12:41
  • 981KB
  • 下载

RDS读写分离,海量数据一键搞定

简介 RDS为用户提供高透明,高可用,高性能,高灵活的读写分离服务。在最近的版本我们基于短连接的用户进行了优化,使得短连接的用户负载均衡更加完善合理。RDS读写分离有如下特性: 易用/透明...
  • zhoushuntian
  • zhoushuntian
  • 2017年12月15日 17:44
  • 22

容器化.NET应用的.NET微服务架构

  • 2017年12月04日 21:01
  • 14.2MB
  • 下载

Diamanti容器融合存储基础架构

前一段时间我们介绍了一款容器定义存储产品,文章分了上下两篇,容器定义存储(CDS)—存储技术的"瘦身"革命和容器定义存储(CDS)—春江水暖"Portworx"先知,文章介绍了容器定义存储的背景和未来...
  • swingwang
  • swingwang
  • 2016年10月17日 22:08
  • 1359
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:容器化RDS|计算存储分离架构下的IO优化
举报原因:
原因补充:

(最多只允许输入30个字)