容器化 RDS|计算存储分离架构下的 IO 优化
技术
作者:熊中哲
译者:
2018-01-24 12:13

 
导语:在基于 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-IO 优化


1.DoubleWrite

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


简单说 DoubleWrite 的实现,是防止数据页写入时发生故障导致页损坏 (partialwrite),所以每次写数据文件时,都要将一份数据写到共享表空间中。当启动时发现数据页 Checkum 校验不正确时,会使用共享表空间中副本进行恢复,从 DoubleWrite 实现来看这部分会产生一定量的 IO。所以,最好的优化就是减少 IO,在底层存储介质或文件系统支持 Atomic Write 的前提下,可以关闭 MySQL 的 DoubleWrite 以减少 IO。


2.单机架构:关闭 DoubleWrite

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





结论就是:单机环境下,启用 Atomic Write (关闭 DoubleWrite )能立即带来 30% 左右的写性能改善。原文地址 : http://blog.mariadb.org/mariadb-introduces-atomic-writes/

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

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

测试场景 

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


测试结果:10GB 数据量 


Sysbench 指标

分布式文件系统指标



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

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


测试结果:100GB 数据量 


Sysbench 指标


分布式文件系统指标:



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

END

298 comCount 0