当前位置: 澳门新濠3559 > 服务器运维 > 正文

玄惭被誉为双 11 护航老司机,地理距离与数据中

时间:2019-11-08 03:17来源:服务器运维
业务和管理需求使得数据中心管理和灾难恢复的缺陷更加明显。二十年前,用货车运输磁带进行存储就能满足需求了。十年前,两个数据中心的距离只要能进行I/O,就能满足需求。现在

业务和管理需求使得数据中心管理和灾难恢复的缺陷更加明显。二十年前,用货车运输磁带进行存储就能满足需求了。十年前,两个数据中心的距离只要能进行I/O,就能满足需求。现在,随着电子商务成为首要的负载,恢复计划还得考虑数据中心的地理距离,这一点限制了恢复时间。

摘要: 如同Oracle存在与之匹配的OCFS2,POLARDB作为存储与计算分离结构的一款数据库,PolarFS承担着发挥POLARDB特性至关重要的角色。PolarFS是一款具有超低延迟和高可用能力的分布式文件系统,其采用了轻量的用户空间网络和I/O栈构建,而弃用了对应的内核栈,目的是充分发挥RDMA和NVMe SSD等新兴硬件的潜力,极大地降低分布式非易失数据访问的端到端延迟。

IT宕机可能对任何业务产生重大影响。传统情况下,这使得备份数据恢复的速度成为IT团队的主要焦点。然而,即使备份工具得到改进,许多组织的恢复时间仍然不够。此外,此前的高可用性系统已经超出了大多数组织的财务可接受范围。

地理距离与数据中心管理

随着国内首款Cloud Native自研数据库POLARDB精彩亮相ICDE 2018的同时,作为其核心支撑和使能平台的PolarFS文件系统的相关论文"PolarFS: An Ultra-low Latency and Failure Resilient Distributed File System for Shared Storage Cloud Database"也被数据库顶级会议VLDB 2018录用。8月,阿里云数据库团队亮相于巴西里约召开的VLDB 2018,对整个业界起到了非常积极的影响。

现如今,提供数据中心高可用性是一种不同的,更具成本效益的方法:即数据镜像以及云计算和容器的使用。

澳门新濠3559 1

概念上,这是关于两个不同位置的数据中心,如图1所示。在数目也许会扩展到更多站点。

VLDB(Very Large Data Base)和另外两大数据库会议SIGMOD、ICDE构成了数据库领域的三个顶级会议。VLDB国际会议于1975在美国的弗雷明汉马 (Framingham MA) 成立,是数据库研究人员,供应商,参与者,应用开发者,以及用户一年一度的顶级国际论坛。

选择容器

对不少商家而言,双 11 销量往往是平时的N倍。

澳门新濠3559 2 
图1:地理性分离数据中心的示意图

VLDB主要由四个主题构成,分别为:Core Database Technology ,Infrastructure for Information Systems ,Industrial Applications and Experience 以及 Experiments and Analyses。

澳门新濠3559 3

云数据库如何从容应对双 11 当日的流量高峰?

图中两个数据中心是分离的,这对于进行同步磁盘输入输出来说,实在太远了,这导致了很多需求。首先每个数据中心必须得有自己的直接存取存储设备Direct Access Storage Device,简称DASD)场所来进行管理。第二是同步硬件复制会因为网络延迟而无法工作。最后,距离也意味着,每个数据中心的逻辑分区logical partition,简称LPAR)不能处于同一个SysplexSystems Complex,系统联合体)里面。

从09年至今的数据分析来看,VLDB的论文接受率总体是比较低,其中,核心数据库主题中的论文接受率大概为16.7%;基础设施信息系统方面的论文接受率大约为17.9%;工业应用与经验的论文接收比例近视为18%;而实验和分析部分的为19%左右。由此可见,论文被VLDB接收不是件容易的事情,必须是创新性很高,贡献很大的论文才有机会被录用。

容器可以帮助解决与高可用性系统相关的一些重要问题。例如,假设您的数据完全镜像到辅助站点。现在,假设主站点遇到问题。您有对您的数据有完全访问权限,但应用程序呢?即使您可以故障切换到镜像数据,没有应用程序也是毫无办法的。现在,您必须等待您在镜像站点上提供应用程序,或者支付可能很高的金额才能在该站点上运行应用程序的实时版本——只是以防万一。

今天,特别邀请到 ApsaraDB 团队的大牛级人物玄惭和大家分享,结合历年双十一活动中云数据库保障经验,从弹性扩容、访问链路、架构设计、高可用配置、参数优化等五个方面详解讲解云数据库大流量峰值保障的最佳实践。

网络在数据中心管理中占了重要位置,是两个数据中心之间的切换开关。有了合适的内部通讯系统,以后的要求都可以基于不同标准,按路线分给每个数据中心。其实,有了现在基于浏览器的应用,用户可以实现不同数据中心的不间断切换。

本文着重介绍PolarFS的系统设计与实现。

然而,容器,可在某一很小的单一系统内容纳完整的应用程序。虽然虚拟机在整个堆栈中运行所有内容,从操作系统向上,容器只携带它们所需要的内容,并与其他容器共享底层操作系统。

玄惭被誉为双 11 护航老司机。过去五年,他一直负责天猫双 11 项目的数据库运维,0 故障,0 丢单。

因为硬件复制不可用,数据必须在逻辑数据库或者访问方式access method)的级别上被获取。有几个产品可以做这件事。部分产品得通过读数据库或Virtual Storage Access Method简称VSAM)记录来升级。变更投到其他数据中心,通过通信线路使用多种的传输协议。在接收端,由另一个软件发给数据库或访问方式命令来完成远程升级。

如同Oracle存在与之匹配的OCFS2,POLARDB作为存储与计算分离结构的一款数据库,PolarFS承担着发挥POLARDB特性至关重要的角色。PolarFS是一款具有超低延迟和高可用能力的分布式文件系统,其采用了轻量的用户空间网络和I/O栈构建,而弃用了对应的内核栈,目的是充分发挥RDMA和NVMe SSD等新兴硬件的潜力,极大地降低分布式非易失数据访问的端到端延迟。目前,PolarFS的3副本跨节点写入的访问总延迟已经非常接近单机本地PCIe SSD的延迟水平,成功地使得POLARDB在分布式多副本架构下仍然能够发挥出极致的性能。

在上面的示例中,IT团队可以用较低成本在辅助站点上存储容器集合。随后,如果主站点遇到问题,他们可以在几分钟内启动应用程序容器以访问镜像的数据。

1、弹性扩容的两种方式

为相隔两地的数据中心配置

针对数据库设计分布式文件系统会带来以下几点好处:

当您在公共云中选择辅助站点时,云存储的成本非常低,低到在此示例中容器存储的成本将是微不足道的。当您实际需要启动容器时,成本会变得明显,但是与停机时间的全部业务成本相比,使用工作系统的成本仍然会降低。

多数用户在双十一到来之前都会进行弹性扩容。

分离的数据中心有好几种方式来配置,能想到的有以下几种:

计算节点和存储节点可以使用不同的服务器硬件,并能独立地进行定制。例如,计算节点不需要考虑存储容量和内存容量的比例,其严重依赖于应用场景并且难以预测。

对于宕机容忍度比较低的组织来说,可以不断地启动容器,而不是存储它们,并在必要时使用它们。此时成本会更高,但是如果主站点发生故障,系统可以几乎实时地平滑地将故障转移到备份站点。您还可以通过支付弹性资源来最小化成本;一个未使用的启动容器将不会使用很多CPU或网络资源。当主站点发生故障并发生故障转移时,您只需要增加资源。

常见的弹性扩容分为两类:本机升降级和跨机升降级。

Hot-warm

多个节点上的存储资源能够形成单一的存储池,这能降低存储空间碎化、节点间负载不均衡和空间浪费的风险,存储容量和系统吞吐量也能容易地进行水平扩展。

来自数据镜像的挑战

本机升降级的话,比较简单。举个栗子,一个 6G/6C 的 RDS 数据库想要升级到 12G/12C,如果本机资源足够,则可以在本机完成升降级,无需迁移到其他机器上。

企业中一个数据中心被指派成为所有网络流量的目标。在第一个数据中心的升级会被复制到第二个数据中心站点,第二个会接收并把这些改变用在本地的DASD场所。一旦第一个数据中心故障,若第二个站点在线,混乱会降至最低。

数据库应用的持久状态可下移至分布式文件系统,由分布式存储提供较高的数据可用性和可靠性。因此数据库的高可用处理可被简化,也利于数据库实例在计算节点上灵活快速地迁移。

遗憾的是,镜像数据并不像看起来那么容易。距离是其中的主要问题;镜像站点越远,存在的延迟越高,维持数据的保真度就越难。另外,如果发生数据损坏,你最不想做的事情就是镜像损坏部分的数据。

澳门新濠3559 4

升级-查询

此外,云数据库服务也会因此带来额外的收益:

如果您的组织需要通过持续的高可用性系统来保证业务连续性,则必须为高级数据镜像服务支付费用。云服务提供商(如Amazon Web Services和Microsoft Azure)现在拥有可实现远程数据镜像的高速数据连接。但是,具有数据备份的快照可能是一个较为经济的选项。快照从实时系统创建数据的只读副本。它不需要将实时系统锁定或暂停运转,并且在CPU和I/O利用率方面很有效率。快照有不同的方法,但是写时复制方法是上述要求的最佳选择。快照捕获对数据系统的每次写入,并将其作为后台任务写入主存储系统和远程系统。通过这些方法,您可以在容器旁快速启动快照数据集,以在辅助站点上创建运行的系统。

另一种弹性扩容的方式是:跨机升降级。

在升级-查询的方案中,一个数据中心地区全体升级,而其他只允许查询。升级的站点为只读的系统联合体及时带来改变。如果升级数据中心失败,负责查询的系统联合体得负全责。

云数据库可以采用虚拟计算环境如KVM等部署形态,其更安全、更易扩展和更易升级管理。

容器也变得对数据更加敏感。例如,它们可以容纳作为持久存储的数据卷。通过使用容器编排系统(container orchestration systems),可以将数据快照从主站点同步到远程容器。当前,这在高可用性系统中可能难以实现,但市场将如何发展是值得关注的。

当本机资源不足以支撑升级所需要的资源的时候,需要将实例分配到另外一台机器上。所以跨机升级需要使用数据库最近一次的备份和日志实时同步到新的主机上,保证新实例和旧实例的数据是完全一致的。

网络在进行这种安装时,起决定性作用,它必须能问信息内容,来区分询问和升级事务。工作站可能也会使用网络来平衡负载,使每个数据中心能够带上属于自己的只读流量。

一些关键的数据库特性,如一写多读实例、数据库快照等可以通过分布式文件系统的数据共享、检查点等技术而得以增强。

【编辑推荐】

这里需要注意的坑是:如果历史备份集较大或原主库压力较大时,会导致跨机迁移时间较长。

升级-升级

澳门新濠3559 5

澳门新濠3559 6

这是个实实在在的事。每个数据中心支持所有数据的所有升级。两种方式的复制流经通信连接,保持数据库的同步。一旦发生故障,没有出问题的数据中心承担所有即将到来的流量。

系统组件

那些老司机踩过的坑:

注意当两个数据中心都升级时,数据在逻辑上可能会分离。比如说对用户的初级数据库在密西西比河西边的“A数据中心”,第二个只读的数据在“B数据中心”。用户在哪一边都可能是反向的。最终,这意味着网络必须足够智能,知道客户的初级数据在哪。

PolarFS系统内部主要分为两层管理:

  • 如果升级很长时间也没有完成,可能发生了跨机迁移或者主备存在延迟。
  • 可用区迁移、数据库版本升级耗时通常较长,是因为两者迁移都会发生跨机迁移。
  • 空间升级非常快,这是因为空间升级无需重启、迁移数据库,对业务也不会造成影响。
  • 弹性扩容时间的选择,建议在业务低峰期进行弹性扩容。

其他的问题

存储资源的虚拟化管理,其负责为每个数据库实例提供一个逻辑存储空间。

2、双 11 期间,如何让访问链路更安全?

相信各位深思熟虑的读者已经想到不少这些问题。但是还有更多令人不安的不稳定因素。

文件系统元数据的管理,其负责在该逻辑存储空间上实现文件管理,并负责文件并发访问的同步和互斥。

在云数据库中,访问链路分为两种模式:高安全访问链路和标准访问链路。

批处理——在升级-升级的模式下,生产量会问题多多。企业得决定哪一方进行批处理,如果批处理两方都得进行就更头疼了。还得考虑对带宽的需求,用以从I/O相关批处理事务中挤出空间升级,通过复制链接。

PolarFS的系统结构如图所示:

双 11 期间,流量高的网站也会成为黑客的重点关注对象。所以建议商家提前采用高安全访问链路。

复制的延迟——现代通信连接又快有可靠,但还会有问题。就算是最快最完美的通信线也不能和DASD I/O一样同步和快速。因此,系统基础架构和一部分应用必须准备好应对延迟和“过时”的数据。

澳门新濠3559 7

澳门新濠3559 8

冲突问题——数据库管理系统Database Management Systems,简称DBMS)在不同的系统联合体中,不能从太宽的距离锁定数据库记录。这导致在不同数据中心内,相同的数据库记录可能会同时升级。基础设施和应用需要准备好应对混乱。

• libpfs是一个用户空间文件系统库,负责数据库的I/O接入。

高安全访问链路在数据库的前面增加了一层代理层,所有请求在代理层都被解析,在解析过程中添加了 SQL 拦截规则,进而可以防止 SQL 注入的攻击。

控制改变——基础设施、应用和数据库设计的改变一定得认真管理,避免破坏在不同数据中心复制的一致性。

• PolarSwitch运行在计算节点上,用于转发数据库的I/O请求。

此外,高安全访问链路可以防止 90% 的连接闪断;并支持内外网地址同时访问;对短连接应用具有缓冲防护作用。

漂移——没有异步复制技术在逻辑I/O层面是完美的,企业会发现分叉数据存储变慢。整理这些不同需要周期性的调和进程。

• ChunkServer部署在存储节点上,用于处理I/O请求和节点内的存储资源分布。

需要注意的是高安全访问链路较标准链路增加了 5% 左右的响应时间。

死亡——对于数据中心来说,什么算死?数据中心通过复制流量和heartbeat来保持联系。但是复制流量的减慢可能预示着一个数据中心工作做的少了。同样地,一些遗落的heartbeat也暗示着网络故障或减慢,而不是数据中心故障。

• PolarCtrl是系统的控制平面,它包含了一组实现为微服务的管理者,相应地Agent代理被部署到所有的计算和存储节点上。

那些老司机踩过的坑:

探查和遵照这些察觉到的故障来行事,要求精心策划的政策、高度自动化和仔细的管理。好消息是数据中心的地理分离逐渐变得平常,解决这些问题的政策也变得更加便于学习。

在进一步介绍各部分之前,我们先来了解下PolarFS存储资源的组织方法:

  • 建议使用高安全访问模式,特别是短连接应用,高安全访问模式具有缓冲短连接对数据库冲击的效果。
  • 在标准访问链路切换到高安全访问链路时,切换过程最多会有30秒不可访问。
  • 如果ECS使用VPC,那么数据库只能选择高安全访问链路。
  • 访问链路上需要注意应用不要使用IP来访问数据库,避免由于IP变化导致故障。

...

PolarFS的存储资源管理单元分为3层:Volume、Chunk、Block。

3、双 11 的架构如何设计?

Volume

在历年的双 11 中,由于业务流量的突增,那些平时没有暴露出来的问题往往在这个时候爆发出来,所以我们要把数据库这块地基打好,细节上做好,架构设计就需要我们在这些上下功夫。

Volume是为每个数据库提供的独立逻辑存储空间,其上建立了具体文件系统供此数据库使用,其大小为10GB至100TB,可充分适用于典型云数据库实例的容量要求。

澳门新濠3559 9

在Volume上存放了具体文件系统实例的元数据。文件系统元数据包括inode、directory entry和空闲资源块等对象。由于POLARDB采用的是共享文件存储架构,我们在文件层面实现了文件系统元数据一致性,在每个文件系统中除DB建立的数据文件之外,我们还有用于元数据更新的Journal文件和一个Paxos文件。我们将文件系统元数据的更新首先记录在Journal文件中,并基于Paxos文件以disk paxos算法实现多个实例对Journal文件的互斥写访问。

读写分离是常见的架构设计手段。

Chunk

RDS 支持只读节点,主库主要承担写和实时性要求高操作,一些复杂的分析计算业务操作最好不要放在主库上执行,而是选择放在只读节点运算。

每个Volume内部被划分为多个Chunk,Chunk是数据分布的最小粒度,每个Chunk只存放于存储节点的单个NVMe SSD盘上,其目的是利于数据高可靠和高可用的管理。典型的Chunk大小为10GB,这远大于其他类似的系统,例如GFS的64MB。

使用读写分离架构时,首先数据库版本需要升级到 MySQL 5.6 版本;同时目前 RDS 最多可以支持到五个只读节点。

这样做的优势是能够有效地减少Volume的第一级映射元数据量的大小(例如,100TB的Volume只包含10K个映射项)。一方面,全局元数据的存放和管理会更容易;另一方面,这使得元数据可以方便地缓存在内存中,从而有效避免关键I/O路径上的额外元数据访问开销。

在读写分离时,延时是我们必须关注的重点,目前 RDS 上通过源码改进并行复制,提升复制性能,降低了主库与备库之间数据同步的延迟。

但这样做的潜在问题是,当上层数据库应用出现区域级热点访问时,Chunk内热点无法进一步打散,但是由于我们的每个存储节点提供的Chunk数量往往远大于节点数量(节点:Chunk在1:1000量级),PolarFS可支持Chunk的在线迁移,并且服务于大量数据库实例,因此可以将不同实例的热点以及同一实例跨Chunk的热点分布到不同节点以获得整体的负载均衡。

引擎选择是数据库设计中很基础的一点,这里重点介绍下 Tokudb 引擎。日志型应用的特性是:写操作很高、读操作相对较少。Tokudb 引擎压缩比 Innodb 引擎高出 5~7 倍,适合写多读少的应用;同时,Tokudb 引擎 online ddl 速度较快,适合表很大需要经常 DDL 操作的应用。

Block

对于大字段,数据库的更新写入压力过大,update、insert、delete 会导致 binlog 日志急剧增加,导致实例磁盘报警。因此在数据库设计时,要注意规避大字段引起的问题。常见的大字段有 varchar(8000)、text、blob、clob(sqlserver/mysql),使用时建议将大字段拆分出主表或者存入到其他存储系统中。

在ChunkServer内,Chunk会被进一步划分为多个Block,其典型大小为64KB。Blocks动态映射到Chunk 中来实现按需分配。Chunk至Block的映射信息由ChunkServer自行管理和保存,除数据Block之外,每个Chunk还包含一些额外Block用来实现Write Ahead Log。我们也将本地映射元数据全部缓存在ChunkServer的内存中,使得用户数据的I/O访问能够全速推进。

字段类型也是常见的问题之一。在设计开发阶段,就要避免数据库字段定义与应用程序参数定义不一致的情况。

下面我们详细介绍PolarFS的各个系统组件。

字段大小同样会对数据库性能造成影响。字段长度超过索引允许的最大长度会导致索引字段被截断;同时,过长的字段定义会消耗大量的排序内存以及临时表空间。

libpfs

索引设计也是大家经常犯错的一个点,在历年双十一保障中,索引出现的问题最多。

libpfs是一个轻量级的用户空间库,PolarFS采用了编译到数据库的形态,替换标准的文件系统接口,这使得全部的I/O路径都在用户空间中,数据处理在用户空间完成,尽可能减少数据的拷贝。这样做的目的是避免传统文件系统从内核空间至用户空间的消息传递开销,尤其数据拷贝的开销。这对于低延迟硬件的性能发挥尤为重要。

这里,重点讲解单条SQL的创建索引思路,常见的索引误区包括但不限于:

其提供了类Posix的文件系统接口,因而付出很小的修改代价即可完成数据库的用户空间化。

  • 对SQL语句的每个查询条件字段建立一个单列索引,MySQL 只能使用其一个索引;
  • 对SQL语句的所有查询字段建立组合索引,导致索引远大于数据,同时性能低下;
  • 小表不建立索引。

澳门新濠3559 10

4、双 11 的高可用配置如何搞?

PolarSwitch

RDS 本身是一个主备的高可用架构,当主库 Down 后,会快速切换到备库。在高可用架构中很重要的一点是数据同步,保障主备数据一致不丢失。

PolarSwitch是部署在计算节点的Daemon,它负责I/O请求映射到具体的后端节点。数据库通过libpfs将I/O请求发送给PolarSwitch,每个请求包含了数据库实例所在的Volume ID、起始偏移和长度。PolarSwitch将其划分为对应的一到多个Chunk,并将请求发往Chunk所属的ChunkServer完成访问。

常见的高可用配置包括:

ChunkServer

  • 单可用区:主备都在同一个可用区内,可以实现主备之间的快速切换;
  • Binlog 同步:采取异步和半同步的方式保障主备的数据一致;
  • Binlog 刷写:根据应用特点设置安全模式或者高性能模式;
  • 事务提交:默认采用最高安全模式。

ChunkServer部署在后端存储节点上。一个存储节点可以有多个ChunkServer。每个ChunkServer绑定到一个CPU核,并管理一个独立的NVMe SSD盘,因此ChunkServer之间没有资源争抢。

此外,为了保障服务高可用,也可以采用多可用区配置,即主备在不同可用区,此时,应用同样需要多可用区部署。需要注意 Binlog 在主备的同步模式,通常这种情况下开启半同步模式跨可用区访问,可能导致写入性能下降。

ChunkServer负责Chunk内的资源映射和读写。每个Chunk都包括一个WAL,对Chunk的修改会先进Log再修改,保证数据的原子性和持久性。ChunkServer使用了3DXPoint SSD和普通NVMe SSD混合型WAL buffer,Log会优先存放到更快的3DXPoint SSD中。

另外,还有一种跨数据中心的灾备方案,在历年的双 11 中,已经有很多用户实施过这样的方案,你可以选择在两个不同的数据中心部署数据库和应用,比如在杭州和上海两个地区部署,两个数据中心的数据同步采用 DTS,以保证一个数据中心挂掉后,另外一个数据中心能够接管起来。

ChunkServer会复制写请求到对应的Chunk副本(其他ChunkServer)上,我们通过自己定义的Parallel Raft一致性协议来保证Chunk副本之间在各类故障状况下数据正确同步和保障已Commit数据不丢失。

此外,从 2015 年起,RDS 为天猫的商家后台数据库提供了异地灾备的功能。当主机房出现较大的负载压力、断网、断电等极端情况,RDS 可将商家的后台系统在 30 分钟内切换至灾备机房继续运行,以保障总体可靠性,进一步确保平台大型品牌商家双 11 期间后台系统安全、稳定。

PolarCtrl

5、针对双 11,如何做参数优化?

PolarCtrl是PolarFS集群的控制核心。其主要职责包括:

在 RDS 中,大部分参数是已经经过调优的,因此很多参数是不需要再去调整的。

  1. 监控ChunkServer的健康状况,确定哪些ChunkServer有权属于PolarFS集群;

  2. Volume创建及Chunk的布局管理(即Chunk分配到哪些ChunkServer);

  3. Volume至Chunk的元数据信息维护;

  4. 向PolarSwitch推送元信息缓存更新;

  5. 监控Volume和Chunk的I/O性能;

  6. 周期性地发起副本内和副本间的CRC数据校验。

但是用户可以根据应用场景的不同选择合适的参数,这里重点看下 RDS 新增的四个参数优化:

PolarCtrl使用了一个关系数据库云服务用于管理上述metadata。

  • rds_max_tmp_disk_space:控制 MySQL 能够使用的临时文件的大小,适用于一个 SQL 语句就消耗掉整个数据库的磁盘空间;
  • tokudb_buffer_pool_ratio:控制 TokuDB 引擎能够使用的 buffer 内存大小,适用于选择了 tokudb 作为存储引擎的场景;
  • max_statement_time:控制单个 SQL 语句的最长执行时间,适用于控制数据库中的慢 SQL 数量;
  • rds_threads_running_high_watermark:控制 MySQL 并发的查询数目,常用于秒杀场景的业务;

分布式系统的设计有两种范式:中心化和去中心化。中心化的系统包括GFS和HDFS,其包含单中心点,负责维护元数据和集群成员管理。这样的系统实现相对简单,但从可用性和扩展性的角度而言,单中心可能会成为全系统的瓶颈。去中心化的系统如Dynamo完全相反,节点间是对等关系,元数据被切分并冗余放置在所有的节点上。去中心化的系统被认为更可靠,但设计和实现会更复杂。

看完了“玄惭大师”的经验分享, 那么,你对大流量峰值下保障云数据库有什么好的经验可以分享吗?

PolarFS在这两种设计方式上做了一定权衡,采用了中心统控,局部自治的方式:PolarCtrl是一个中心化的master,其负责管理任务,如资源管理和处理控制平面的请求如创建Volume。ChunkServer负责Chunk内部映射的管理,以及Chunk间的数据复制。当ChunkServer彼此交互时,通过ParallelRaft一致性协议来处理故障并自动发起Leader选举,这个过程无需PolarCtrl参与。

【编辑推荐】

PolarCtrl服务由于不直接处理高并发的I/O流,其状态更新频率相对较低,因而可采用典型的多节点高可用架构来提供PolarCtrl服务的持续性,当PolarCtrl因崩溃恢复出现的短暂故障间隙,由于PolarSwitch的缓存以及ChunkServer数据平面的局部元数据管理和自主leader选举的缘故,PolarFS能够尽量保证绝大部分数据I/O仍能正常服务。

下面我们通过一个I/O的处理来说明各组件的互动过程。

澳门新濠3559 11

PolarFS执行写I/O请求的过程如上图所示:

  1. POLARDB通过libpfs发送一个写请求,经由ring buffer发送到PolarSwitch。

  2. PolarSwitch根据本地缓存的元数据,将该请求发送至对应Chunk的主节点。

  3. 新写请求到达后,主节点上的RDMA NIC将写请求放到一个提前分好的buffer中,并将该请求项加到请求队列。一个I/O轮询线程不断轮询这个请求队列,一旦发现新请求到来,它就立即开始处理。

4. 请求通过SPDK写到硬盘的日志block,并通过RDMA发向副本节点。这些操作都是异步调用,数据传输是并发进行的。

  1. 当副本请求到达副本节点,副本节点的RDMA NIC同样会将其放到预分buffer中并加入到复制队列。

  2. 副本节点上的I/O轮询线程被触发,请求通过SPDK异步地写入Chunk的日志。

  3. 当副本节点的写请求成功回调后,会通过RDMA向主节点发送一个应答响应。

8. 主节点收到一个复制组中大多数节点的成功返回后,主节点通过SPDK将写请求应用到数据块上。

  1. 随后,主节点通过RDMA向PolarSwitch返回。

  2. PolarSwitch标记请求成功并通知上层的POLARDB。

ParallelRaft协议设计动机

一个产品级别的分布式存储系统需要确保所有提交的修改在各种边界情况下均不丢失。PolarFS在Chunk层面引入一致性协议来保证文件系统数据的可靠性和一致性。设计之初,从工程实现的成熟度考虑,我们选择了Raft算法,但对于我们构建的超低延迟的高并发存储系统而言,很快就遇到了一些坑。

Raft为了简单性和协议的可理解性,采用了高度串行化的设计。日志在leader和follower上都不允许有空洞,其意味着所有log项会按照顺序被follower确认、被leader提交并apply到所有副本上。因此当有大量并发写请求执行时,会按顺序依次提交。处于队列尾部的请求,必需等待所有之前的请求已被持久化到硬盘并返回后才会被提交和返回,这增加了平均延迟也降低了吞吐量。我们发现当并发I/O深度从8升到32时,I/O吞吐量会降低一半。

Raft并不十分适用于多连接的在高并发环境。实际中leader和follower使用多条连接来传送日志很常见。当一个链接阻塞或者变慢,log项到达follower的顺序就会变乱,也即是说,一些次序靠后的log项会比次序靠前的log项先到。但是,Raft的follower必需按次序接收log项,这就意味着这些log项即使被记录到硬盘也只能等到前面所有缺失的log项到达后才能返回。并且假如大多数follower都因一些缺失的项被阻塞时,leader也会出现卡顿。我们希望有一个更好的协议可以适应这样的情形。

由于PolarFS之上运行的是Database事务处理系统,它们在数据库逻辑层面的并行控制算法使得事务可以交错或乱序执行的同时还能生成可串行化的结果。这些应用天然就需要容忍标准存储语义可能出现的I/O乱序完成情况,并由应用自身进一步保证数据一致性。因此我们可以利用这一特点,在PolarFS中依照存储语义放开Raft一致性协议的某些约束,从而获得一种更适合高I/O并发能力发挥的一致性协议。

我们在Raft的基础上,提供了一种改进型的一致性协议ParallelRaft。ParallelRaft的结构与Raft一致,只是放开了其严格有序化的约束。

乱序日志复制

Raft通过两个方面保障串行化:

1. 当leader发送一个log项给follower,follower需要返回ack来确认该log项已经被收到且记录,同时也隐式地表明所有之前的log项均已收到且保存完毕。

2. 当leader提交一个log项并广播至所有follower,它也同时确认了所有之前的log项都已被提交了。ParallelRaft打破了这两个限制,并让这些步骤可乱序执行。

因此,ParallelRaft与Raft最根本的不同在于,当某个entry提交成功时,并不意味着之前的所有entry都已成功提交。因此我们需要保证:

  1. 在这种情况下,单个存储的状态不会违反存储语义的正确性;

  2. 所有已提交的entry在各种边界情况下均不会丢失;

澳门新濠3559,有了这两点,结合数据库或其他应用普遍存在的对存储I/O乱序完成的默认容忍能力,就可以保证它们在PolarFS上的正常运转,并获得PolarFS提供的数据可靠性。

ParallelRaft的乱序执行遵循如下原则:

1. 当写入的Log项彼此的存储范围没有交叠,那么就认为Log项无冲突可以乱序执行;

  1. 否则,冲突的Log项将按照写入次序依次完成。

容易知道,依照此原则完成的I/O不会违反传统存储语义的正确性。

接下来我们来看log的ack-commit-apply环节是如何因此得到优化并且保持一致性的。

• 乱序确认:当收到来自leader的一个log项后,Raft follower会在它及其所有之前的log项都持久化后,才发送ack。ParallelRaft则不同,任何log entry成功持久化后均能立即返回,这样就优化了系统的平均延迟。

• 乱序提交:Raft leader串行提交log项,一个log项只有之前的所有项提交之后才能提交。而ParallelRaft的leader在一个log项的多数副本已经确认之后即可提交。这符合存储系统的语义,例如,NVMe SSD驱动并不检查读写命令的LBA来保证并行命令的次序,对命令的完成次序也没有任何保证。

• 乱序应用:对于Raft,所有log项都按严格的次序apply,因此所有副本的数据文件都是一致的。但是,ParallelRaft由于乱序的确认和提交,各副本的log都可能在不同位置出现空洞,这里的挑战是,如何保证前面log项有缺失时,安全地apply一个log项?

ParallelRaft引入了一种新型的数据结构look behind buffer来解决apply中的问题。

  1. ParallelRaft的每个log项都附带有一个look behind buffer。look behind buffer存放了前N个log项修改的LBA摘要信息。

  2. look behind buffer的作用就像log空洞上架设的桥梁,N表示桥梁的宽度,也就是允许单个空洞的最大长度,N的具体取值可根据网络连续缺失log项的概率大小,静态地调整为合适的值,以保证log桥梁的连续性。

  3. 通过look behind buffer,follower能够知道一个log项是否冲突,也就是说是否有缺失的前序log项修改了范围重叠的LBAs。没有冲突的log项能被安全apply。如有冲突,它们会被加到一个pending list,待之前缺失的冲突log项apply之后,才会接着apply。

通过上述的异步ack、异步commit和异步apply,PolarFS的chunk log entry的写入和提交避免了次序造成的额外等待时间,从而有效缩减了高并发3副本写的平均时延。

ParallelRaft协议正确性

我们在ParallelRaft的设计中,确保了Raft协议关键特性不丢失,从而保障了新协议的正确性。

  1. ParallelRaft协议的设计继承了原有Raft协议的Election Safety、Leader Append-Only及Log Matching特性。

  2. 冲突log会以严格的次序提交,因此协议的State Machine Safety特性能够最终得以保证。

3. 我们在Leader选举阶段额外引入了一个Merge阶段,填补Leader中log的空洞,能够有效保障协议的Leader Completeness特性。

文件系统多副本高速写入——数据库单实例的超高TPS,数据高可靠

PolarFS设计中采用了如下技术以充分发挥I/O性能:

  1. PolarFS采用了绑定CPU的单线程有限状态机的方式处理I/O,避免了多线程I/O pipeline方式的上下文切换开销。

2. PolarFS优化了内存的分配,采用MemoryPool减少内存对象构造和析构的开销,采用巨页来降低分页和TLB更新的开销。

3. PolarFS通过中心加局部自治的结构,所有元数据均缓存在系统各部件的内存中,基本完全避免了额外的元数据I/O。

4. PolarFS采用了全用户空间I/O栈,包括RDMA和SPDK,避免了内核网络栈和存储栈的开销。

在相同硬件环境下的对比测试,PolarFS中数据块3副本写入性能接近于单副本本地SSD的延迟性能。从而在保障数据可靠性的同时,极大地提升POLARDB的单实例TPS性能。

下图是我们采用Sysbench对不同负载进行的初步测试比较。

  1. POLARDB on PolarFS

  2. Alibaba MySQL Cloud Service RDS

澳门新濠3559 12

用例负载:OLTP,只读、只写(update : delete : insert = 2:1:1)、读写混合(read : write = 7:2)。数据库测试集数据量为500GB。

可以发现POLARDB在PolarFS下取得了较好的性能,PolarFS同时支持了POLARDB的高TPS和数据的高可靠性。

文件系统共享访问——写多读的数据库QPS强扩展,数据库实例的Failover

PolarFS是共享访问的分布式文件系统,每个文件系统实例都有相应的Journal文件和与之对应的Paxos文件。Journal文件记录了metadata的修改历史,是共享实例之间元数据同步的中心。Journal文件逻辑上是一个固定大小的循环buffer。PolarFS会根据水位来回收journal。Paxos文件基于Disk Paxos实现了分布式互斥锁。

由于journal对于PolarFS非常关键,它们的修改必需被Paxos互斥锁保护。如果一个节点希望在journal中追加项,其必需使用DiskPaxos算法来获取Paxos文件中的锁。通常,锁的使用者会在记录持久化后马上释放锁。但是一些故障情况下使用者不释放锁。为此在Paxos互斥锁上分配有一个租约lease。其他竞争者可以重启竞争过程。当PolarFS当节点开始同步其他节点修改的元数据时,它从上次扫描的位置扫描到journal末尾,将新entry更新到memory cache中。

下图展示了文件系统元数据更新和同步的过程。

澳门新濠3559 13

  1. 节点1分配块201至文件316后,请求互斥锁,并获得。

  2. Node 1开始记录事务至journal中。最后写入项标记为pending tail。当所有的项记录之后,pending tail变成journal的有效tail。

3. Node1更新superblock,记录修改的元数据。与此同时,node2尝试获取node1拥有的互斥锁,Node2会失败重试。

4. Node2在Node1释放lock后拿到锁,但journal中node1追加的新项决定了node2的本地元数据是过时的。

5. Node2扫描新项后释放lock。然后node2回滚未记录的事务并更新本地metadata。最后Node2进行事务重试。

  1. Node3开始自动同步元数据,它只需要load增量项并在它本地重放即可。

PolarFS的上述共享机制非常适合POLARDB一写多读的典型应用扩展模式。一写多读模式下没有锁争用开销,只读实例可以通过原子I/O无锁获取Journal信息,从而使得POLARDB可以提供近线性的QPS性能扩展。

由于PolarFS支持了基本的多写一致性保障,当可写实例出现故障时,POLARDB能够方便地将只读实例升级为可写实例,而不必担心底层存储产生不一致问题,因而方便地提供了数据库实例Failover的功能。

文件系统级快照——POLARDB的瞬时逻辑备份

对于百TB级超大数据库实例的备份而言,数据库快照是必须支持的功能。

PolarFS采用了自有的专利快照技术,能够基于位于底层的多个ChunkServer的局部快照,构建Volume上的统一的文件系统即时映像。POLARDB利用自身数据库的日志,能够基于此文件系统映像快速构建出此具体时点的数据库快照,从而有效支持数据库备份和数据分析的需求。

澳门新濠3559 14

可以发现,POLARDB的高性能、强扩展、轻运维等具备竞争优势的优异特性,与PolarFS的紧密协作息息相关,PolarFS发挥了强大的使能作用。

PolarFS是一个专为云数据库而设计的分布式文件系统,其能够支持跨节点高可靠性同时提供极致的性能。PolarFS采用了新兴硬件和先进的优化技术,例如OS-bypass和zero-copy,使得PolarFS中数据块3副本写入性能接近于单副本本地SSD的延迟性能。PolarFS在用户空间实现了POSIX兼容接口,使得POLARDB等数据库服务能够尽量少地修改即可获得PolarFS带来的高性能的优势。

可以看到,面向数据库的专有文件系统,是保障未来数据库技术领先的一个不可或缺的关键一环。数据库内核技术的进展及其专有文件系统的使能,是一个相辅相成的演进过程,二者的结合也会随着当今系统技术的进步而愈加紧密。

未来我们将探索NVM和FPGA等新硬件,以期通过文件系统与数据库的深度结合来进一步优化POLARDB数据库的性能。

本文作者:桐碧2018

阅读原文

本文为云栖社区原创内容,未经允许不得转载。

编辑:服务器运维 本文来源:玄惭被誉为双 11 护航老司机,地理距离与数据中

关键词: