阿里数据库的极致弹性之路

数据库的Share Nothing分布式扩展已经深入人心，存储计算分离会不会回到IOE状态?如果IDC是一个数据中心，应用就是计算，DB就是存储，DB自己再做存储计算分离有意义吗?数据是主备双副本的，存储计算分离后变成三副本，存储集群的容量池化能balance掉额外副本的成本吗?

为此我开始测算存储计算分离架构在大促场景下的投入产出，我们来看下大促场景，弹性大促时，业务需求计算能力数倍甚至10倍以上扩容，承担大促峰值压力，而磁盘因为存储长期数据，峰值的数据量在整体占比不高，因此磁盘容量基本不需要扩容。

在以前本地磁盘跑主备的架构，无法计算、存储分开扩容，大促指标越高，添加标准机器越多，成本浪费越大，因为磁盘是标准数据库机器的主要成本。而存储计算分离的情况下，测算下来，我们看到在较低日常压力下存储计算分离成本是比本地盘高的，但再往上，存储计算分离只需要增加计算，存储集群因为池化后，不只容量池化了，性能也池化了，任何高负载实例的IO都是打散到整个集群分担的，磁盘吞吐和IOPS复用，不需扩性能，成本优势非常明显。

磁盘不扩容，只扩计算自然成本低很多。传统的思考是存储集群容量池化的优势，但在大促场景我们更多用到的是性能的池化，突破单机瓶颈，因此我们提出了电商异地多活所有单元存储计算分离，其余业务继续使用本地磁盘进行同城容灾的目标架构。

提出这个设想，而这个架构的可行性如何判断?基于一些数字就可以推断，大家知道SSD磁盘的读写响应时间在100-200微秒，而16k的网络传输在10微秒内，因此尽管存储计算分离增加两到三次的网络交互，加上存储软件本身的消耗，整体有机会做到读写延时在 500微秒的范围内。在数据库实例压测中我们发现，随着并发增加，存储集群具备更大的QPS水位上线，这印证了性能池化突破单机瓶颈带来的吞吐提升。

数据库团队在2017年开始验证存储计算分离，基于25G的TCP网络实现存储计算分离部署，当年就承担了10%大促流量。我们基于分布式存储做到了700微秒的响应时间，这里内核态和软件栈的消耗较大，为此X-DB也针对性地做了慢IO优化，特别是日志刷盘的优化，开启原子写去掉了double write buffer提升吞吐能力。

这个过程中，我们沉淀了存储的资源调度系统，目前已经作为统一调度的组件服务集团业务。我们对当前架构性能不太满意，有了X-DB的慢IO优化、存储计算分离跨网络的IO路径、存储资源调度等技术沉淀，加上阿里巴巴RDMA网络架构的发展，2017下半年数据库开始和盘古团队一起，做端到端全用户态的存储计算分离方案。

四、全用户态IO链路的存储计算分离架构落地

从数据库软件X-DB的IO调用开始，就走我们自己研发的用户态文件系统DBFS，DBFS使用盘古的用户态客户端，直接通过RDMA网络访问后端盘古分布式文件系统，整个IO链路完全绕过了内核栈。这里DBFS绕过了内核文件系统，自然也绕过了pagecache，为此DBFS针对数据库场景，实现了更简洁高效的BufferIO机制。

因为IO都是跨网络远程访问，因此RDMA起到了重要作用，以下是RDMA与TCP网络在不同包大小下的延时对比，除了延时优势外，RDMA对长尾IO的tail latency能够有效控制，对一个数据库请求涉及多次IO来说，对用户请求的响应时间能够更有效保证。RDMA技术的应用是DB大规模存储计算分离的前提条件，通过我们的数据实测，DBFS+RDMA链路的延时已经和Ext4+本地盘达到相同水平。

今年我们首次大规模部署RDMA，如履薄冰。经过多次压测、演练， RDMA配套监控和运维体系建设已经完善起来，我们能够在1分钟内识别服务器网卡或交换机的网络端口故障触发告警，能够故障快速隔离，支持业务流量快速切走，支持集群或单机的网络RDMA向TCP降级切换等等。在我们的切流演练中，从DBFS看到RDMA链路的写延时比TCP降低了一倍。我们在全链路压测中，基于RDMA技术保障了在单个数据库实例接近2GB吞吐下磁盘响应时间稳定在500微秒左右，没有毛刺。

盘古分布式存储为了同时支持RDMA、EC压缩、快照等功能，做了大量的设计优化，尤其对写IO做了大量优化，当然也包括RDMA/TCP切流，故障隔离等稳定性方面的工作。作为阿里的存储底盘，其在线服务规模已经非常庞大。

整个技术链路讲清楚之后，说一下我们在规模应用中遇到的难题，首先，容器的网络虚拟化Bridge和RDMA天然不兼容，由于容器走Bridge网络模式分配IP，而这个是走内核的。为了应用RDMA，我们必须使用Host网络模式进行容器化，走Host + X-DB + DBFS + RDMA +盘古存储这样的全用户态链路。

其次，对于公有云环境，我们通过VPC打通形成混合云环境，因此应用通过VPC访问数据库，而数据库使用物理IP用于RDMA访问盘古以及X-DB内部X-Paxos。这个方案复杂而有效，得益于DBPaaS管控的快速迭代和容器化资源调度的灵活性，这些新技术能够快速落地，在变化中稳步推进。

今年年初，我们定下了2018大促的支撑形态，即异地多活的中心机房将计算弹性到大数据的离线资源，单元机房将计算弹性到公共云资源，不搬数据直接弹性扩容，快上快下的大促目标。今年DB全局一盘棋，完成了资源调整，实现了电商各站点的存储计算分离架构升级，并通过X-DB异地多副本架构灵活部署，实现了弹性大促目标。

基于底层盘古分布式的共享存储，弹性不需要迁移数据，只需要挂载磁盘，数据库可以像应用一样快速弹性，做到一个集群10分钟完成弹性扩容。同时在全链路压测过程中，对出现性能瓶颈的业务，我们可以边压边弹，快速弹到更大的规格上。基于快速弹性的能力，今年DB所有站点的大促扩容都在三天内完成，这在以前是不可能实现的，这就是存计分离的架构带来的效率。

最后，感谢阿里内部通力合作的盘古、网络、调度、IDC等团队，正是大家的支持让阿里数据库的基础架构才能不断升级，不断提升效率和成本的竞争力。

数据库存储计算分离的架构升级，大大节约了大促资源成本。目前我们的弹性能力正在日常化，通过数据预测，自动触发弹性扩容，我们的目标是让单机容量问题导致故障成为历史。

接下来我们平台将向智能化发展，对于数据库来说，只有基础架构足够强大，足够快速，灵活，弹性，智能化才能有效发挥。

（编辑：财气旺网 - 财气网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!