你好,游客 登录
背景:
阅读新闻

构建云上企业数据库架构分为哪五步?

[日期:2017-12-19] 来源:云栖团队博客  作者: [字体: ]

  阿里巴巴高级数据库架构师黄欢欢在2017云栖大会苏州峰会上与大家分享了云上企业数据库架构之路。主要分享了构建企业级数据库架构包括异地多活、数据库容器化、混合云架构、计算存储分离和数据库与离线混布,其中包含X-DB、HDM等重要云产品。

  以下是精彩视频内容整理:

  做数据库架构需要满足三个基本需求。第一个问题是扩展,业务高速发展,单地资源容量受限;第二个问题是弹性,双十一对弹性扩展和收缩的需求;第三个问题是成本,在尽可能小的预算成本内完成业务目标。

  为了满足这三个需求,阿里巴巴在数据库架构上做了很多探索和改进,包括异地多活升级、数据库容器化、混合云架构、计算存储分离和数据库与离线混布。

  异地多活

大数据

  从数据库的角度看异地多活,从设计原则上要遵循两个规则。第一,数据要从一个角度进行拆分,保证数据不会被双写;第二,单元内实现业务封闭,比如下单过程中要登录、扣库存、扣优惠,登录在一个单元里,扣库存跳到另外一个单元,这就会导致混乱。所以,数据库的设计比较简单:每个Region独立的DRDS集群,Region之间DTS数据实时传输。

  多活的基础:DTS

  DTS可以打通各种异构数据源间的数据流动,让数据发挥更大的业务价值,它源自阿里去IOE及异地多活架构的实践。典型的业务场景比如异地多活,单元间的数据同步可以通过DTS实时同步/分发,延迟都在秒级别内;另外,异构数据源之间的迁移同样可以通过DTS进行实现。

  X-DB多region部署

  不是所有数据都能在各个Region中写入,比如库存数据一般只在单点写、多点读,在这种业务场景下,如果使用原来的业务架构,当一个中心挂掉实现异地容灾时,由于单元之间的数据是异步同步的,切过来后可能出现数据不是强一致。对此,我们提供了第二代分布式关系型数据库X-DB。

  库存业务通过X-DB多Region部署如图,主备5节点保证主节点每一个写日志一定需要同步超过3个以上的备节点才能够返回业务成功。所以,X-DB的优点包括以下四个方面:

  Region级的强一致性,做到单个Region不可用0数据丢失;

  高性能。跨Region强同步下依然保持高性能;

  灵活的切换策略。优先切换同Region,定制跨Region切换顺序;

  高伸缩性。可无限制的扩充Region/AZ的节点,可自由的调节Region/AZ内节点。

  DB容器化

  异地多活升级后,下一步开始尝试做数据库容器化。

  一方面,我们做了AliSQL in Docker,通过统一的一层调度支持数据库二层调度,比如主备容器规格一样。AliSQL in Docker支持数据库业务逻辑的调度策略,构建了完善的资源隔离方案,已经做到了100%容器化;

  另一方面,我们做了AliSQL in 高性能ECS,使用了SPDK+NVMe存储和DPDK网络,整体上测试得出,与同等规格物理机相比,虚拟化带来的损耗降到了最低,性能降低5%以下。

  数据库容器化是数据库构建起可扩展架构的基础部分,只有做完容器化,才可能实现架构的进一步演进。

  弹性混合云

  在日常的流量下,用户可以跑在自建IDC下,大促期间使用弹性混合云架构,大促前将数据库弹性扩展上去,大促结束后将申请的ECS资源返还回去,扩上去和弹下来可以在一个月内完成。为什么我们有这么快的弹性伸缩能力?这依赖于新的云产品混合云数据库管理平台。

  我们可以做到一键构建新的数据库云单元,混合云数据库管理主要提供三大块内容:

  统一管理:HDM可以进行云上云下数据库统一管理;

  快速弹性:比如原来数据库在云下,大促时在云上加只读节点, 大促结束后再销毁只读节点。也可以在云上快速建立起大规格资源,支撑完业务后再弹下来,最大限度享受云资源的弹性能力;

  容灾切换:自建IDC出现问题时,HDM提供了数据库容灾切换能力,包括云上切换云下,或云下切换云上。

  计算存储分离

  完成异地多活架构、数据库容器化和混合云架构后,我们仍然与应用不一样,应用容器化后可以快速调度,但数据库还不行,为什么?因为应用是无状态的,而数据库是有状态的,数据库下面拖有数据,如果有持久化数据,就没办法与应用一样做到弹性能力,因此,我们只有进行计算存储分离。

  那么,为什么要做计算存储分离?原因有以下四点:

  第一, 要做更好的弹性能力就要把DB去状态化,将计算节点和存储分开,使调度变得更简单;

  第二, 解除计算和存储Bond,如果计算节点需要扩2倍、存储节点需要扩4倍,分别对计算和存储进行扩容。另外,将数据放在统一的存储里,磁盘碎片会大大减少;

  第三, 计算节点不再需要冗余,节省了成本;

  第四, 为数据库在线和离线任务的混部提供了基础。

  数据库计算存储分离架构如图,AliSQL为计算层,计算层与存储层之间使用25G TCP/RDMA网络,存储层按照一定的规则和数据可靠性要求将数据打散在不同的Rack和集群中。

  做计算和存储分离面临的技术挑战很大,对吞吐和时延的要求非常高。我们需要在各个维度做很多优化,包括:

  分布式存储优化:长尾时延优化,写三反二;Partial recovery,降低对线上业务的影响。

  数据库优化:AliSQL 吞吐优化,提升100%;原子写优化,关闭double write buffer,提高吞吐;时延接近本地盘。

  软硬件优化:引入RDMA网络协议,SPDK用户态文件系统等。

  DB与离线混部

  为了进一步减少成本,我们将数据库与离线任务混部在一起。

  实现计算存储分离后,离在线混部即成为可能,大促时可以借助离线机器计算资源,存储资源仍旧放在分布式存储中。可以看到,在大促时,将数据库计算节点弹到离线机器上去,与离线任务一起跑;在日常运行时,离线和在线任务调度到DB节点,提高资源利用率。那么,如何保障资源隔离呢?我们做了CPU独立socket,避免L3 cache干扰,同时进行了NetQos打标,保证优先级。此外,我们也在离在线混部时构建了弹性能力,使计算节点快上快下,MySQL BP和容器规格动态扩缩容。

  通过异地多活、X-DB、容器化、混合云、计算存储分离以及DB离线混部共同构建了企业级数据库架构。

  以上由云栖社区志愿者小组整理,毛鹤校审,编辑:郭雪梅





收藏 推荐 打印 | 录入:Cstor | 阅读:
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数
点评:
       
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款