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

本文探讨了在基于Kubernetes和Docker的私有RDS中,计算存储分离架构对数据库IO性能的影响。通过关闭MySQL的DoubleWrite特性,实现了在网络延迟和带宽限制下的性能优化,尤其是在100GB数据量场景下,性能提升显著。文章还强调了在计算存储分离架构中数据安全性的重要性,并提出了面临的挑战。
摘要由CSDN通过智能技术生成

在基于 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 的驱逐机制时

  • 1
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值