容器化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%复现这个场景，通过在 K