关于摩尔定律由于基于 Flash 闪存存储设备的出现 ; 处理器, 内存和存储设备终于都可以遵循摩尔定律实现快速的发展. 12 核心, 24 DDR4 500K IOPS, 9us 延迟 50TB

Size: px

Start display at page:

Download "关于摩尔定律由于基于 Flash 闪存存储设备的出现 ; 处理器, 内存和存储设备终于都可以遵循摩尔定律实现快速的发展. 12 核心, 24 DDR4 500K IOPS, 9us 延迟 50TB"

因胥
5 years ago
Views:

1 谈 PCIe ssd 在数据库优化中的作用 II 之颠覆性创新 Apr 2015 Shannon Systems 宝存科技

2 关于摩尔定律由于基于 Flash 闪存存储设备的出现 ; 处理器, 内存和存储设备终于都可以遵循摩尔定律实现快速的发展. 12 核心, 24 DDR4 DRAM@2133MHz 500K IOPS, 9us 延迟 50TB

3 当谈及数据库应用的存储方案时容量性能安全性应用成本 Flash 存储起到的作用

4 基于 Host 的 PCIe Flash 存储的优化与方案超大容量高可用 Flash 存储 (Ultra-capacity and highly available Flash) 原子写 (Atomic Write) Redo log 优化 (Redo log optimization)

5 大容量 Flash 存储 (Ultra Capacity Flash Storage) 常规方案 : HBA 软 RAID 缺点不支持 Flash 存储设备的高级特性, 比如 Trim, S.M.A.R.T 信息等. 性能损耗容错性差, 风险高, 如意外掉电数据安全性问题, 连续故障等.

6 大容量 Flash 存储 (Huge Capacity Flash Storage) 轮转式校验数据存储, 最多可有一个 SSD 故障由于没有校验数据缓存, 数据的随机写入会导致 : 在系统层面, 写放大系数一定大于 2( 过大 ). 更快速的寿命损耗. 会出现写洞现象, 影响数据一致性. 6

7 RAID5 处理随机数据写入的步骤 4K 随机写第一步 : 写入待写数据当磁盘 A 被数据填满时, 会发生写放大现象 7

8 RAID5 处理随机数据写入的步骤 4K 随机写第二步 : 读取原校验数据 8

9 RAID5 处理随机数据写入的步骤 4K 随机写第三步 : 计算出新的校验数据 9

10 Random writes in RAID-5 4K 随机写第四步 : 更新校验数据 10

11 大容量 Flash 存储 (Huge Capacity Flash Storage) 由于 RMW(read-modify-write), RCW(read-reconstruct-write) 导致了物理双写, 使整个 Array 的 WAF( 写放大因子 ) 远远大于 2 在 RMW, RCW 过程中如果系统出现其他故障可导致交验数据更新不成功, Write Hole( 写洞 ) 现象产生, 带来数据一致性问题.

12 大容量 Flash 存储 (Huge Capacity Flash Storage) 随机写性能不是随着阵列中的磁盘数量线性增长. 8 盘 (RAID-5) vs 4 盘 (RAID-5) 12

13 PCIe-RAID

14 PCIe-RAID 目的 : 满足应用程序的大容量需求避免单点故障 ( 硬件故障, 多发性 Flash 芯片失效, 主控失效等.) 解决传统的 RAID5 阵列写性能极差的问题解决传统的闪存盘阵列会有很大的写放大现象. 解决传统 SSD 硬盘性能稳定性和性能一致性不足的问题目标 : 在系统中提供一个集大容量, 高性能和高可靠性的逻辑块设备.

15 PCIe-RAID 技术关键点 : 软件 FTL 层跨设备 FTL 层基于 PBA 的 RAID 采用 2 维 RAID, 以达到最大的保护效果

16 PCIe-RAID Host-Based 将 FTL 的实现从 Flash 存储设备中移至主机统一 FTL 和 RAID 层, 可以解决传统 RAID 存在的诸多问题 Conventional RAID5 of SSDs The new RAID5 architecture 16

17 PCIe-RAID 2 维 RAID, 最大化数据保护

18 Demo

19 PCIe-RAID 性能 ( 保守 ): 4K RW 30W+ IOPS 4K RR 50W+ IOPS 延迟 : R:80us / W:15us 冗余度 / 维护 : PCIe RAID 5 允许一个 PCIe Flash 设备彻底失效. 未来有可能支持 RAID10 PCIe 接口支持热备设备, 8639 接口支持热插拔, 热维护. 综合 OP 可以最多释放到 15% 以下, 更大的用户空间

20 PCIe-RAID 高密度 2U 服务器, 最多可以部署 6 张全高的 PCI-E 板卡, 如 HP DL380 Gen9 ~50TB 裸容量, 最高 40TB 的用户可用容量 3U 服务器, 最多可以部署 11 张全高的 PCI-E 板卡, 如 Supermicro Gen X9DRX+-F ~90TB 裸容量, 最高 80TB 的用户可用容量

21 PCIe-RAID 优势 : 大容量, 高性能全局垃圾回收 GC 和磨损均衡 (WL) 基于 PBA 的 RAID 构建实现, RAID5 的全局写放大系数远远小于 2, 更高的 Flash 寿命避免 RMW/RCW 避免传统 RAID5 所带来的性能损耗. Host-Base 的 UniFTL 可以感知校验数据状态, 避免写洞 (WriteHole) 21

22 原子写 (Atomic Write) 原子操作 : 读 / 写 Page 和 Buffer. Flash Page: Flash 的原子读取, 写入单位, 多以 4K 为例, 但是在现代 Flash 产品中实际多为 16KB/32KB. InnoDB Page: 是 InnoDB 的原子读取, 写入单位. 一般为 16KB. PCIe Flash Write Buffer( 以 Direct-IO 产品为例 ): 主控中的 SRAM, 3 组, 每组 32KB. InnoDB Double Write buffer: 主机内存中的空间, 用来存储 Double Write 数据, 2MB

23 原子写 (Atomic Write) 传统硬件和操作系统不能保证 InnoDB Page 写入这一操作的原子性 InnoDB 使用 Double write 这个特性来避免 InnoDB Page 写入不完整的问题. Page Page copy Double write buffer (2MB) Double Write 缺点 : 数据写入量加倍 (Bad For Flash) 增加了写入负载 ( 不是 2 倍 ) Doublewrite (1MB) write Doublewrite (1MB) 共享表空间 recovery write 数据文件 (.ibd)

24 原子写 (Atomic Write) InnoDB Page Size: 16KB Flash Page Size: 32KB 对 NAND Flash 闪存的页进的行读写操作都是原子操作. A nand block Flash Page 如果我们确保将每个 InnoDB Page 一次性的写入一个 Flash Page(InnoDB Page Size<= Flash Page Size), 那么 InnoDB Page 写入就是原子操作. 保证 InnoDB Page 数据存储不跨 Flash Page.

25 原子写 (Atomic Write) Direct-IO 产品中原子写的实现 InnoDB Page Size 16KB InnoDB Write Request Size 16KB ( 多数情况 ) Flash( 主控 ) Write Buffer Size 32KB *3 Flash Page Size 32KB InnoDB Page 16K Write Request 16K Write Buffer 32K Write Request 16K flush Atomic Flash Page 32K

26 原子写 (Atomic Write) 当 Request Size <= Flash Write Buffer(32KB) 时 Flash Write Buffer 为空时 bio 所有数据先入 Write Buffer, 再刷入 Flash Page. Write buffer Nand page 在突然断电时, 只有完全写入了 Flash Write Buffer 的 BIO(block io) Request 会被刷入 NAND bio 闪存的页没有完全被写入 Flash Write Buffer 的 bio(block io) 会被丢弃. 保证小于 32KB(InnoDB Page 16K) 写入操作的原子性. Flush on power cut

27 原子写 (Atomic Write) 如果 Flash Write Buffer 是 Half Full 的. Write Request Size <= Free Space of Flash Write Buffer 同上 bio Write buffer bio Nand page Write Request Size > Free Space of Flash Write Buffer 将本组 Write Buffer 剩余空间用垃圾数据填充, 新开一组 Write Buffer 来承接这个新的 Write Request. bio Flush on power cut

28 原子写 (Atomic Write) 有时连续的写请求会被合并为一个大 BIO(Block IO) Write Request > Flash Page Size 32K bio Write buffer 数据会不经过 Write Buffer 被直接写入一个新的 Flash Page( 延迟稍高 ). bio

29 原子写 (Atomic Write) 应用原子写的条件 Write Request Size <= Write Buffer Size 32KB 16KB <= 32KB 不要在 MySQL/InnoDB/ 文件系统 / 块设备层面, 分割 / 合并任何 BIO O_DIRECT, Double Write=0 Flash FTL 可感知 BIO 的相关信息, Host-Base Flash Only. Shannon 或 Fusion-IO(SanDisk)

30 原子写 (Atomic Write) 应用原子写的效益 Double Write = 0 性能提升 TPS ~10% (Shannon Systems Lab) 延迟降低 ~50% (Shannon Systems Lab) Flash 存储产品的寿命 200%, 可靠性增强.

31 Shannon vs Fusion-IO Fusion-IO Shannon 1, 必须要使用 DFS 2, 使用特殊 API (Patched App). 1, 可以在任何文件系统中被使用. 2, 与现有文件系统使用相同的 API.

32 Redo Log 优化 (Redo log optimization) InnoDB 具有先写日志特性. redo log 落地后, 就认为数据库完整. redo log: 写入单位 512 Byte, 顺序写. Flash Storage( 以 Direct-IO 产品为例 ) Write Buffer: 32KB *3 Direct-IO 主控 : 2 Data Pipelines 每个 Data Pipeline 独占一组 Write Buffer 32KB 2 个 Pipelines 共享最后一组 Write Buffer, 抢占, 锁数据入 Write Buffer, 向上汇报写入完成, 后台 Flush Data to Nand, 掉电保护由硬件完成.

33 Redo Log 优化 (Redo log optimization) 我们能做什么? 如果我们预留一组 Pipeline 和 Write Buffer. 专门处理 redo log 在 Driver 中调高此种 BIO 的优先级. 期望收益 : 性能提升问题 : 如何将 redo log 的 IO 请求, 与其他的 IO 请求进行区分? 如何让 Driver 感知特殊类型的 IO?

34 Redo Log 优化 (Redo log optimization) 解决方法 : 在应用 /FS 层对 redo log 的 IO 请求加入特殊的 Flag, 用来识别这种特殊 IO 请求. Patch MySQL/InnoDB Patch FS/EXT4

35 Redo Log 优化 (Redo log optimization) Flag 的选择 Linux 系统中所有的 io 请求都会用 summit_bio() 来进行下发 bio(bio_request) 是在 <linux/bio.h> 中定义的结构体.

36 Redo Log 优化 (Redo log optimization) bio 数据结构 struct bio { sector_t bi_sector; /* associated sector on disk */ struct bio *bi_next; /* list of requests */ struct block_device *bi_bdev; /* associated block device */ unsigned long bi_flags; /* status and command flags */ unsigned long bi_rw; /* read or write? */ unsigned short bi_vcnt; /* number of bio_vecs off */ unsigned short bi_idx; /* current index in bi_io_vec */ unsigned short bi_phys_segments; /* number of segments after coalescing */ unsigned short bi_hw_segments; /* number of segments after remapping */ unsigned int bi_size; /* I/O count */ unsigned int bi_hw_front_size; /* size of the first mergeable segment */ unsigned int bi_hw_back_size; /* size of the last mergeable segment */ unsigned int bi_max_vecs; /* maximum bio_vecs possible */ struct bio_vec *bi_io_vec; /* bio_vec list */ bio_end_io_t *bi_end_io; /* I/O completion method */ atomic_t bi_cnt; /* usage counter */ void *bi_private; /* owner-private method */ bio_destructor_t *bi_destructor; /* destructor method */ };

37 Redo Log 优化 (Redo log optimization) unsigned long bi_flags; /* status and command flags */ 无符号长整型, 64bit. 约定第 16bit 设置为 1 来标记 redo log 的 io 请求 EXT4_PRIO_FL=16, MySQL/InnoDB Flag BIO_RW_PRIO=16, FS/EXT4 Flag

38 Redo Log 优化 (Redo log optimization) Patch MySQL/InnoDB os_file_create_func os_file_set_nocache 设置 redo log 文件为 O_DRIECT 判断文件类型, 如果为 OS_LOG_FILE 设置 Flag, 使用 ioctl 将 Flag 交给 FS flags = flags EXT4_PRIO_FL; ioctl(file, EXT2_IOC_SETFLAGS, &flags);

39 Redo Log 优化 (Redo log optimization) Patch FS/EXT4 判断 MySQL/InnoDB 传下来的 flag if (EXT4_I(inode)->i_flags & EXT4_PRIO_FL) 设置 Flag 传给 Direct-IO Driver bio->bi_flags = bio->bi_flags (1 << BIO_RW_PRIO);

40 Redo Log 优化 (Redo log optimization) Flash Storage Driver 保留一个 Data Pipeline 和一组 Write Buffer( 二者绑定 ) 判断 bio->bi_flags & (1 << bio_rw_prio) 将符合条件的 BIO 优先下发给保留的 Pipleline 和 Write Buffer.

41 Redo Log 优化 (Redo log optimization) redo log 优化应用条件 Patched MySQL/InnoDB 改动不会超过 20 行. Patched FS/EXT4 etc. 改动不会超过 20 行. Shannon Direct-IO PCIe SSD Enable Atomic Write Feature when Direct-IO Driver loads Enable redo log optimize Feature when Direct-IO Driver loads

42 Redo Log 优化 (Redo log optimization) redo log 优化效益性能提升 > 100% (In Shannon Systems Lab) NOTE: 如果没有 Patch MySQL/InnoDB FS/EXT4 就在 Direct-IO Dirver 中开启 redo log optimize 特性 Direct-IO 产品性能表现会变差, 因为资源一直被预留不被使用. 开启 redo log optimize 特性后, 如果直接关闭该特性. 会有非常小的几率引发一个 Flash Page 的数据一致性问题. Shannon Systems 建议在关闭之后 reformat Flash Storage

43 当谈及数据库应用的存储方案时容量性能安全性应用成本

44 当谈及数据库应用的存储方案时容量 : 6.4TB/12.8TB 单设备 ( 大容量 ) PCIe RAID( 超大容量 )

45 当谈及数据库应用的存储方案时性能 : 原生 PCIe Flash 本身具有的超高性能. 原子写 (10%) redo log 优化 (>100%)

46 当谈及数据库应用的存储方案时安全性 : 原子写 ( 写入完整性 ) PCIe RAID( 单点, 写洞 ) 掉电数据保护

47 当谈及数据库应用的存储方案时应用成本 : Flash Storage 成本优化空间高密度, 大整合比性能提升带来性价比提升

48 当谈及数据库应用的存储方案时容量性能安全性应用成本

49 Q&A

50 上海宝存信息科技有限公司 Shannon Systems 上海市杨浦区大连路 588 号宝地广场 A 座 305 室 Suite 305 Tower A Baoland Plaza 588 Dalian Road Yangpu Shanghai contact@shannon-sys.com Thanks for your time.

51 Flash 存储中的 LBA( 逻辑地址 ) 与 PBA( 物理地址 ) 动态映射传统的 RAID 控制器会仍然将 Flash 存储视为普通的传统硬盘. 存储与传统硬盘有着本质的区别, 即将 LBA 动态映射给 PBA. 51

52 存储中的非动态因素在 Flash 存储中, 物理块地址 (PBA) 是静态因素可以基于静态的 PBA 来构建 RAID 将 FTL 的实现从 Flash 存储中移至主机中将特别有利于基于 PBA 的 RAID 阵列的构建. 52

53 在 FTL 层构建 RAID 的原理 (1) 初始状态数字代表 LBA 区块代表 PBA 53

54 在 FTL 层构建 RAID 的原理 (2) 后续状态数字代表 LBA 区块代表 PBA 54

1 o o o CPU o o o o o SQL Server 2005 o CPU o o o o o SQL Server o Microsoft SQL Server 2005

1 o o o CPU o o o o o SQL Server 2005 o CPU o o o o o SQL Server o Microsoft SQL Server 2005 1 1...3 2...20 3...28 4...41 5 Windows SQL Server...47 Microsoft SQL Server 2005 DBSRV1 Microsoft SQL Server

关于摩尔定律 由于基于 Flash 闪存存储设备的出现 ; 处理器, 内存和存储设备终于都可以遵循摩尔定律实现快速的发展. 12 核心, 24 DDR4 500K IOPS, 9us 延迟 50TB

关于摩尔定律由于基于 Flash 闪存存储设备的出现 ; 处理器, 内存和存储设备终于都可以遵循摩尔定律实现快速的发展. 12 核心, 24 DDR4 500K IOPS, 9us 延迟 50TB