阿里妹导读: 数据库从 IOE(IBM 小机, Oracle 商业 DB,EMC 存储)一路走来, 大家都知道数据库是资源重依赖的软件, 对服务器的三大件 CPU, 内存, 磁盘几乎都有要求. 数据库作为广泛使用的数据存储系统, 其 SQL 请求背后涉及的物理读, 逻辑读, 排序过滤等消耗了 IO 和 CPU 资源, 业务 SQL 不同, 执行计划不同, 资源消耗就不同, 因而不同业务对资源规格的需求也不一样. 正因如此, 我们更需要抽象规格, 更好地让不同资源诉求的数据库实例混跑在相同的物理机上, 提升整体利用率. 今天, 阿里资深技术专家天羽为我们讲述阿里数据库的极致弹性之路.
除了日常业务需求, 阿里的双 11 场景, 让我们持续思考如何低成本高效率地支持峰值流量, 把这些思考变成现实, 变成技术竞争力. 在大促资源弹性上有这么几个思路:
使用公共云标准资源弹性, 直接用阿里云的标准资源支撑大促后归还. 这个是最直接的想法, 但这里的难度是业务需求和云资源在性能, 成本上的差距, 不要定制化机器.
混部能力, 存量业务的分类混部, 分时混部. 使用离线资源支撑大促, 既是分类混部, 双 11 零点离线降级, 高峰后在线归还资源也是分时复用.
快上快下, 在有能力使用云, 离线资源后, 尽量缩短占用周期.
碎片化资源, 数据库一直是块石头, 是一个大块完整的规格. 如果把数据库自己的大库变成小库, 就可以使用其他业务的碎片化资源, 包括公共云上的资源.
大促的成本 = 持有资源 X 持有周期, 更通用的资源 (云), 更快的部署(容器化) 是缩短持有周期的关键, 如何更少地使用资源(使用离线或只扩计算资源), 就依赖存储计算分离架构的实施. 沿着极致弹性的目标, 数据库经历了混合云弹性, 容器化弹性, 计算存储分离弹性三个阶段, 基础架构从高性能 ECS 混合云, 容器化混合云, 存储计算分离的公共云和离线混部一步步升级.
基本上架构演进就是每年验证一个单元, 第二年全网铺开, 每年挖个坑然后和团队一起努力爬出来, 每次演进需要跨团队背靠背紧密合作, 快速拿下目标, 这也是阿里最神奇的力量. 借助于底层软硬件技术发展, 一步步的架构升级使得弹性混部越来越灵活和快速.
一, 混合云弹性, 高性能 ECS 应运而生
2015 年之前, 我们的大促弹性叫人肉弹性, 也就是大促要搬机器, 比如集团用云的机型支撑大促, 大促结束后搬机器归还给云. 但就在 2015 年底的一次会议上, 李津问能否把数据库跑到 ECS 上, 如果可以, 就真正帮助了云产品成熟, 当时张瑞和我讨论了一下, 在会议上就答复了: 我们决定试一下. 这个合作非常契合会议主题 "挑战不可能 -- 集团技术云计算战区 12 月月会召集令".
对于数据库跑在虚拟机上, 我们判断最大的消耗在 IO 和网络的虚拟化上, 因此如何做到接近本机性能, 怎么穿透虚拟化就是一个问题. 网络的用户态技术 DPDK 已经比较成熟, 但如何做到足够高的效率, 是否 offload 到硬件来做计算是个问题. 文件系统 IO 的用户态链路有个 Intel 的 SPDK 方案, Intel 推出后各大厂商还在验证中, 还没有规模的应用. 我们就在这个时候启动的这个项目, 叫高性能 ECS. 通过和 ECS 团队紧密合作, 最终我们做到了最差场景高性能 ECS 相比本地盘性能损耗低于 10%.
2016 年在集团通过了日常验证, 2017 年大促开始大规模用云资源直接弹性. 这个项目除了打造高性能 ECS 产品, 更重要的是沉淀了网络和文件 IO 的纯用户态链路技术, 这是一个技术拐点的产生, 为阿里后续存储计算分离相关产品的高性能突破打下了基础.
二, 容器化弹性, 提升资源效率
随着单机服务器的能力提升, 阿里数据库在 2011 年就开始使用单机多实例的方案, 通过 Cgroup 和文件系统目录, 端口的部署隔离, 支持单机多实例, 把单机资源利用起来. 但依然存在如下问题:
内存的 OOM 时有发生
存在 IO 争抢问题
多租户混部存在主机账号等安全问题
数据库主备机型一致性
随着单机部署密度越来越高, 社区 Docker 也开始发展起来, 尽管还不成熟, Docker 本身依赖 Cgroup 做资源隔离, 解决不了 Cgroup 的 IO 争抢或 OOM 问题, 但它通过资源隔离和 namespace 隔离的结合, 尝试对资源规格以及部署做新的定义, 因此我们看到了容器化更多的优势:
标准化规格, 数据库与机型解耦, 主备不需要对称. 这对规模化运维带来极大的效率.
Namespace 隔离带来混部能力, 资源池统一.
不同数据库类型, 不同数据库版本随便混.
让 DB 具备与其他应用类型混部的条件.
2015 年数据库开始验证容器化技术, 2016 年在日常环境中大量使用. 因此在集团统一调度的项目启动后, 我们就定下了 2016 年电商一个交易单元全部容器化支撑大促的目标, 承载交易大盘约 30%, 并顺利完成. 2017 年数据库就是全网容器化的目标, 目前数据库全网容器化比例已经接近 100%.
容器化除了提升部署弹性效率, 更重要的是透明底层资源差异, 在没有启动智能调度 (通过自动迁移提升利用率) 前, 仅仅从容器化带来的机器复用和多版本混部, 就提升了 10 个点的利用率, 资源池的统一和标准部署模板也加快了资源交付效率. 容器化完成了底层各种资源的抽象, 标准化了规格, 而镜像部署带来了部署上的便利, 基于数据库 PaaS 和统一调度层的通力合作, 数据库的弹性变得更加快速灵活, 哪里有资源, 哪里就能跑起数据库.
三, 计算资源极致弹性, 存储计算分离架构升级
实现了容器化混合云, 是不是每年大促使用高性能 ECS, 容器化部署就可以了呢? 其实还是有不足的:
数据库弹性需要搬数据, 把数据搬到 ECS 上是非常耗时的工作.
弹性规模太大, 如果超过公有云售卖周期, 会增加持有成本.
因此如何做到更快, 更通用的弹性能力, 是一个新的技术问题. 随着 2016 年调度的发展, 大家考虑机器是不是应该无盘化, 是不是应该存储计算分离, 从而加快调度效率, 而数据库的存储计算分离更是争议很大.
数据库的 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 所有站点的大促扩容都在三天内完成, 这在以前是不可能实现的, 这就是存计分离的架构带来的效率.
来源: https://yq.aliyun.com/articles/675677