数据库从IOE（IBM小型机、Oracle商业DB、EMC存储）一路走来。大家都知道数据库是一个对资源依赖性很强的软件。服务器的三大部件，CPU，内存，磁盘几乎都需要。数据库作为一种应用广泛的数据存储系统，物理读、逻辑读以及SQL请求背后的排序过滤都会消耗IO和CPU资源。不同的业务SQL，不同的执行计划，导致资源消耗不同。因此，不同的业务对资源规格有不同的要求。需求也不一样。正因如此，我们需要更抽象的规范，更好地让不同资源需求的数据库实例运行在同一台物理机上，以提高整体利用率。今天，资深技术专家阿里天宇为我们讲述了阿里数据库的极致弹性之路。除了日常的业务需求，阿里的双11场景让我们不断思考如何低成本高效率支撑高峰流量，并将这些思考转化为现实和技术竞争力。大促的资源弹性有几种思路：使用公有云的标准资源弹性，直接使用阿里云的标准资源来支持大促后的回流。这是最直接的想法，但这里的难点在于业务需求和云资源在性能和成本上的差距。不要定制机器。股票业务混合部门能力、分类混合部门、分时混合部门。利用线下资源支撑大促，不仅是分类混用，双十一半夜线下降级，高峰过后在线归还资源，也是分时复用。快上快下，在你具备使用云端和线下资源的能力后，尽量缩短占用时间。资源零散，数据库从来都是一块石头，大规格齐全。如果把数据库自己的大库改成小库，就可以利用其他业务的碎片化资源，包括公有云上的资源。大促的成本=持有资源X持有周期，更通用的资源（云），更快的部署（容器化）是缩短持有周期的关键，如何使用更少的资源（使用离线或只扩展计算资源），它取决于存储和计算分离架构的实现。数据库以极致弹性为目标，经历了混合云弹性、容器化弹性、计算存储分离弹性三个阶段。混合系逐步升级。架构演进基本上就是每年验证一个单元，第二年铺开全网，每年挖一个洞，努力和团队一起爬出来。每一次进化都需要跨团队背靠背的紧密配合才能快速实现目标。这是阿里最神奇的地方。的力量。借助底层软硬件技术发展，逐级架构升级，让弹性混合部署更灵活、更快捷。1、混合云弹性、高性能ECS应运而生。2015年以前，我们的大促弹性叫人弹性，就是大促需要搬机器。比如集团用云机型支持大促，大促结束后搬机。返回云端。但在2015年底的一次会议上，李津问能不能把数据库跑在ECS上。如果是这样，那将真正有助于云产品的成熟。一度。此次合作与大会主题“挑战不可能——集团科技云计算战区12月月会号召”完美契合。对于运行在虚拟机上的数据库，我们判断最大的消耗在IO和网络虚拟化上，那么如何做到性能接近本机，如何穿透虚拟化是一个问题。网络的用户态技术DPDK已经比较成熟，但是如何做到足够高的效率，是否卸载到硬件上进行计算，是一个问题。文件系统IO的用户态链接有IntelSPDK解决方案。Intel推出后，各大厂商还在验证中，并没有大规模应用。我们这个时候上线的项目叫高性能ECS。通过与ECS团队的紧密合作，我们最终实现了高性能ECS在最坏情况下相比本地盘的性能损失小于10%。2016年通过集团日常验证，2017年开始大规模直接弹性使用云资源。本项目除了打造高性能的ECS产品，更重要的是沉淀了网络和文件IO的纯用户态链接技术。这是一个技术拐点，为阿里巴巴后续存储计算分离相关产品的高性能突破奠定了基础。.2、容器化弹性提升资源效率随着单机服务器容量的提升，阿里数据库在2011年开始使用单机多实例方案，通过Cgroup和文件系统目录、端口的部署隔离，支持单机多实例，整合单机资源。但是仍然存在以下问题：内存有时会OOM，存在IO竞争问题。多租户混合部署存在主机账号等安全问题。数据库主备模型的一致性。随着单机部署密度越来越大，社区Docker也开始发展起来，虽然还不成熟，Docker本身依赖Cgroup进行资源隔离，无法解决Cgroup的IO争用或OOM问题，但它试图通过资源隔离和命名空间隔离的结合，对资源规范和部署做出新的定义，所以我们看到容器化还有更多的优势：标准化的规范，数据库和模型的解耦，不需要主备对称。这给大规模运维带来了极大的效率。命名空间隔离带来了混合部署和统一资源池的能力。不同的数据库类型，不同的数据库版本，可以随便混用。让DB具备与其他应用类型混用的条件。2015年数据库开始验证容器化技术，2016年广泛应用于日常环境。因此，集团统一调度项目上线后，我们定下目标，将所有电商交易单元集装箱化，支撑2016年的大促，承载约30%的交易市场，并圆满完成。2017年，数据库是全网容器化的目标。目前全网数据库容器化比例接近100%。除了提高部署弹性和效率，容器化更重要的是透明底层资源差异。在智能调度（通过自动迁移提高利用率）之前，容器化只能提高机器复用和多版本混用。10点的使用率得到提升，资源池统一标准的部署模板也加速了资源投放效率。容器化完成了各种底层资源的抽象和规范，而镜像部署带来了部署上的便利。基于数据库PaaS和统一调度层的配合，让数据库的弹性变得更快、更灵活。哪里有资源，哪里就可以运行数据库。3、计算资源极富弹性，升级存储计算分离架构，实现容器化混合云。是不是可以年年推广使用高性能ECS，容器化部署就够了？其实还是有不足的：数据库弹性需要移动数据，将数据移动到ECS是一个非常耗时的工作。弹性规模过大，如果超过公有云销售周期，会增加拥有成本。因此，如何实现更快、更通用的弹性能力是一个新的技术难题。2016年随着调度的发展，大家都在考虑机器要不要无盘，存储和计算要不要分离，这样才能加快调度效率，而数据库的存储和计算分离的争议就更大了。数据库的ShareNothing分布式扩展已经深入人心。存储和计算分离会回到IOE状态吗？如果IDC是数据中心，应用就是计算，DB就是存储。DB把存储和计算分开有意义吗？数据是主备双副本，存储和计算分离变成三副本。存储集群的容量池化能否平衡额外副本的成本？为此，我开始计算大促场景下存储计算分离架构的输入输出。我们来看看大促场景。弹性大促期间，业务的算力需要扩大数倍甚至10倍以上才能承受大促的峰值压力。因为磁盘存储的是长期数据，所以峰值数据量占整体的比例并不高。因此，磁盘容量基本不需要扩容。在以往本地盘主备的架构下，计算和存储无法分开扩展。提升指数越高，加入的标准机越多，成本的浪费就越大，因为磁盘是标准数据库机的主要成本。在存储计算分离的情况下，经过计算可以看出，在日压低的情况下，存储计算分离的成本要高于本地盘，但是再往上，存储计算分离只需要增加计算，不仅有容量池化，还有性能池化。任何一个高负载实例的IO都分发给整个集群共享。磁盘吞吐量和IOPS复用，无需性能扩展，成本优势非常明显。磁盘不扩容，计算成本低很多。传统思维是存储集群容量池化的优势，但是在大促场景中我们更多的是使用性能池化来突破单机的瓶颈。因此，我们提出电商异地多活各单元存储计算分离，其余业务继续使用本地盘进行同城容灾目标架构。提出这个想法，又如何判断这个架构的可行性呢？根据一些数字我们可以推断SSD盘的读写响应时间在100-200微秒，16k的网络传输在10微秒以内，所以虽然存储计算分离增加了两到三倍的网络交互，加上存储软件本身的消耗，整体读写延迟有机会在500微秒以内。在数据库实例压测中，我们发现随着并发量的增加，存储集群有更大的QPS水位，印证了性能池突破单机瓶颈带来的吞吐量提升。数据库团队在2017年开始验证存储计算分离，基于25GTCP网络部署存储计算分离，并承担了当年大促流量的10%。基于分布式存储，我们实现了700微秒的响应时间，其中对内核态和软件栈的消耗比较大。为此，X-DB也对慢速IO进行了优化，特别是logflushing的优化，atomicWrite去除了doublewritebuffer，提高了吞吐量。在这个过程中，我们沉淀了一个存储资源调度系统，现在已经作为一个统一的调度组件服务于集团的业务。我们对当前架构的性能不满意。得益于X-DB慢IO优化、存储计算跨网络IO路径分离、存储资源调度等技术沉淀，加上阿里巴巴RDMA网络架构的发展，该数据库将于2017年下半年启动。与盘古团队一起，实现端到端的全用户态存储计算分离方案。4、实现了全用户态IO链路的存储计算分离架构。从数据库软件X-DB的IO调用开始，我们使用了自己开发的用户态文件系统DBFS。DBFS使用盘古的用户态客户端，直接通过RDMA网络。访问后端盘古分布式文件系统，整个IO链路完全绕过了内核栈。这里DBFS绕过了内核文件系统，自然也就绕过了pagecache。为此，DBFS针对数据库场景实现了更加简洁高效的BufferIO机制。因为IO是通过网络远程访问的，所以RDMA起到了重要的作用。下面是RDMA和TCP网络在不同数据包大小下的延迟对比。除了延迟优势，RDMA还可以有效控制长尾IO的尾部延迟。对于涉及多个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等团队的全力配合。是你们的支持，让阿里数据库的基础设施得以不断升级，不断提升效率和成本竞争力。数据库存储与计算分离的架构升级，大大节省了大促的资源成本。目前，我们的弹性能力正在日常实施中。通过数据预测，自动触发弹性扩容。我们的目标是让单机容量问题导致的故障成为历史。接下来，我们的平台将向智能化方向发展。对于数据库来说，只有基础设施足够强大、足够快、灵活、有弹性、智能，才能得到有效利用。
