开发者社区> 技术小能手> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

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

简介:
+关注继续查看

计算存储分离架构

架构示意图如下:

f3dbc8e85ab8eb687d952f20a4c721378637aed5

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

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

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

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

计算存储分离架构的缺点

俗话说的好:

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

如下图所示

196be2e580c457167c72b6b22ee824b640e7bdec

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

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

其实还有一个极其重要的问题,由于kubernetes 本身没有提供 Voting 服务和类似 Oracle Rac 的 Fence 机制,在计算存储分离架构下,当集群发生脑裂,并触发 Node Controller 和Kubelet 的驱逐机制时,可能会出现多个数据库实例同时访问一份数据文件导致 DataCorruption 的情况,数据的损失对用户而言是不可估量也不可忍受的。

我们在 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 ),并在单机环境做了相关测试。数据如下:

9d5358096bf908095756833f6615a1933472e2c3

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

原文地址 : 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 指标:

98934f028634e26201c10848fe3dc1ee979ea74b

分布式文件系统指标:

771f957687883bee62ba481d96ec0369016ea01a

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

Sysbench指标, 提升不明显

       tps ↑0.2656%,qps ↑0.2797%,rst ↑14.9651%

分布式文件系统指标

       Throughput 下降53%, 显著优化了网络带宽

测试结果 : 100GB数据量

Sysbench 指标:

1182c9ac6dc6ca60a15d14cb0944e3bbd637d530

分布式文件系统指标:

b96c2e5751b75cd499e1cc0322578f50be844614

在计算存储分离架构下, 启用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%


原文发布时间为:2018-01-11

本文作者:熊中哲

本文来自云栖社区合作伙伴“老叶茶馆”,了解相关信息可以关注“老叶茶馆”微信公众号

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
Paper Reading 预告 | 揭秘 PolarDB 计算存储分离架构性能优化之路
12月29日 19:00 锁定「阿里云数据库视频号」揭秘PolarDB计算存储分离架构性能优化之路
0 0
HTAP 架构 - 存储计算分离处理AP查询的挑战
HTAP 架构 - 存储计算分离处理AP查询的挑战
0 0
分离部署lnmp架构
分离部署lnmp架构
0 0
架构之道:分离业务逻辑和技术细节
架构之道:分离业务逻辑和技术细节
0 0
阿里高级技术专家谈开源DDD框架:COLA4.1,分离架构和组件(下)
阿里高级技术专家谈开源DDD框架:COLA4.1,分离架构和组件(下)
0 0
阿里高级技术专家谈开源DDD框架:COLA4.0,分离架构和组件(上)
阿里高级技术专家谈开源DDD框架:COLA4.0,分离架构和组件(上)
0 0
应用架构之道:分离业务逻辑和技术细节
“让上帝的归上帝,凯撒的归凯撒。”
0 0
必备,前台与后台分离的架构实践
技术人,谦虚一点,总是没错的。
367 0
dotnet core webapi +vue 搭建前后端完全分离web架构(一)
架构 服务端采用 dotnet core  webapi   前端采用: Vue + router +elementUI+axios            问题 使用前后端完全分离的架构,首先遇到的问题肯定是跨域访问。
5249 0
+关注
技术小能手
云栖运营小编~
文章
问答
文章排行榜
最热
最新
相关电子书
更多
ECS计算与存储分离架构实践
立即下载
ECS 计算与存储分离架构实践
立即下载
基于英特尔®架构的阿里云服务网格ASM技术加速应用服务加密通
立即下载