宝存科技 吕智超 - 谈PCIe ssd在数据库优化中的作用II之颠覆性创新

芒兴庆

2018/05/13 发布于 技术 分类

今年是中国数据库技术大会第六个年头,大会将继续秉承分享IT最佳应用实践的宗旨,围绕传统数据库和大数据两条技术主线,在目前IT技术和管理快速的大背景下,更加深入地探讨数据库技术的现状和未来的发展方向,以及我们在这个转型过程中的实践经验和教训。

文字内容
1. 谈PCIe ssd在数据库优化中的作用II之颠覆性创新 Apr 2015 Shannon Systems 宝存科技
2. 关于摩尔定律 • 由于基于Flash闪存存储设备的出现;处理器,内存和存储设备终于都可 以遵循摩尔定律实现快速的发展. 12 核心, 24 线程 @3.2Ghz DDR4 DRAM@2133MHz 768GB @2U 500K IOPS, 9us 延迟 50TB 裸容量 @2U
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:'>Page: Flash 的原子读取, 写入单位, 多以4K为例, 但是在现 代Flash产品中 实际多为16KB/32KB. • InnoDB Page:'>Page: 是InnoDB 的原子读取,写入单位. 一般为16KB. • PCIe Flash Write Buffer(以Direct-IO产品为例): 主控中的SRAM, 3 组,每组32KB. • InnoDB Double Write buffer: 主机内存中的空间,用来存储Double Write 数据, 2MB
23. 原子写(Atomic Write) • 传统硬件和操作系统不能保证 InnoDB Page 写入这一操作的原 子性 Page • InnoDB使用Double write这个特 copy 性来避免InnoDB Page写入不完 Page 整的问题. • Double Write 缺点: • 数据写入量加倍(Bad For Flash) • 增加了写入负载(不是2倍) write Doublewrite Doublewrite (1MB) (1MB) 共享表空间 Double write buffer (2MB) write recovery 数据文件 (.ibd)
24. 原子写(Atomic Write) • InnoDB Page Size:'>Size: 16KB • Flash Page Size:'>Size: 32KB • 对NAND Flash 闪存的页进的行读写操作都是 原子操作. • 如果我们确保将每个InnoDB Page 一次性的写 入一个Flash Page(InnoDB Page Size<= Flash Page Size),那么InnoDB Page 写入就 是原子操作. • 保证InnoDB Page 数据存储不跨 Flash Page. A nand block 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) 时 Write buffer • • Flash Write Buffer 为空时 所有数据先入Write Buffer, 再刷入Flash Page.bio 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 Request Size > Free Space bio of Flash Write Buffer • 将本组Write Buffer 剩余空间用垃圾 数据填充, 新开一组Write Buffer 来 承接这个新的Write Request. Write buffer Nand page bio Flush on power cut
28. 原子写(Atomic Write) • 有时连续的写请求会被合并为一个大 BIO(Block IO) • Write Request > Flash Page Size 32K bio • 数据会不经过Write Buffer被直接写 入一个新的 Flash Page(延迟稍高). bio Write buffer
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 1, 必须要使用DFS 2, 使用特殊API (Patched App). Shannon 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)是在中定义的结构体.
36. Redo Log 优化(Redo log optimization) • bio 数据结构 struct bio { sector_t struct bio struct block_device unsigned long unsigned long unsigned short unsigned short unsigned short unsigned short unsigned int unsigned int unsigned int unsigned int struct bio_vec bio_end_io_t atomic_t void bio_destructor_t }; bi_sector; *bi_next; *bi_bdev; bi_flags; bi_rw; bi_vcnt; bi_idx; bi_phys_segments; bi_hw_segments; bi_size; bi_hw_front_size; bi_hw_back_size; bi_max_vecs; *bi_io_vec; *bi_end_io; bi_cnt; *bi_private; *bi_destructor; /* associated sector on disk */ /* list of requests */ /* associated block device */ /* status and command flags */ /* read or write? */ /* number of bio_vecs off */ /* current index in bi_io_vec */ /* number of segments after coalescing */ /* number of segments after remapping */ /* I/O count */ /* size of the first mergeable segment */ /* size of the last mergeable segment */ /* maximum bio_vecs possible */ /* bio_vec list */ /* I/O completion method */ /* usage counter */ /* owner-private method */ /* 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 200082 021-5558-0181 contact@shannon-sys.com www.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