2.1 基于MINIO的对象存储方案在探探的实践于乐

2020-03-01 553浏览

1.基于MINIO的对象存储⽅方案在探探的实践于乐探探科技 yule@tantanapp.com
2.
3.存储现状 1200TB 900TB 600TB 300TB 0TB 原始图⽚片裁剪图⽚片视频⾳音频
4.调研⽬目前已有的开源⽅方案 Ambry FastFS MogileFS TFS
5.
6.初探 MINIO
7.MINIO 架构
8.数据分布以及可靠性 ● Drive, 可以简单理理解为⼀一块硬盘 ● Set ，⼀一组 Drive 的集合 ● ⼀一个对象存储在⼀一个 Set 上 ● ⼀一个集群划分为多个 Set ● ⼀一个 Set 包含的 Drive 数量量是固定的 ● ● ● 默认由系统根据集群规模⾃自动计算得出 MINIO_ERASURE_SET_DRIVE_COUNT ⼀一个 SET 中的 Drive 尽可能分布在不不同节点上
9.数据编码 Erasure Code, a mathematical algorithm to reconstruct missing or corrupted data. ● 将⼀个对象编码成若⼲个数据块和跟校验块 ● Reed-Solomon ● 低冗余，⾼可靠 Bit Rot Protection ● HighwayHash
10.
11.上传下载流程
12.IO 实现细节
13.巧⽤用 channel
14.如何部署 # 启动⼀一个12个节点的 minio 集群，每个节点有12个drive minio serverhttp://10.3.1.{1…12}/data{1…12}
15.性能压测 ● CosBench ● 参考 Minio 官⽅方压测⽅方案 ● 不不同⼤大⼩小，不不同并发，不不同读写⽐比例例组合测试
16.12 个节点，每个节点 12 块盘，混合读写 64KB
17.多集群扩容
18.MINIO Limitation ● 集群搭建后之后不不允许扩容 ● ⼤大集群最⼤大节点数为 32 ● Dsync 分布式锁
19.“ We can certainly do single large namespace, but then taking one cluster down can potentially be a large downtime and a very complex deployment. This is exactly what we did with GlusterFS for 10yrs. This why most storage solutions never scale beyond few PBs. Minio's fundamental design is to avoid such practical issues in production and make managing clusters easier. Failures are common in real world scenarios and when it's a gigantic pool, it is very hard to know what is going on. You can avoid these details in your application, if you are clever about it on how you lookup URLs. —— Harshavardhana ”
20.扩容⽅方案 • 可同时向多个集群写⼊ • 集群容量到达阈值，从写集群中剔除，变成只读 • 读取的时候根据编码到⽂件名上的集群信息，从⽽路由到正确的集群
21.万事俱备，只⽋欠东⻛风 ● 筹划数据迁移 ● 准备接⼊入服务 ● 采购机器器
22.⽣生活并不不是⼀一帆⻛风顺的
23.实际流量量测试 ● ● ● ● 100ms 200ms 500ms 报警！
24.S3 下载响应时间
25.S3 上传响应时间
26.Minio 上传性能
27.MINIO Profile # 开始采集整个集群指定 profile 类型的数据，类型可选 'cpu', 'mem', 'block', 'mutex', ‘trace' mc admin profile start -type cpu # 结束采集，⾃自动下载采集结果⽂文件 mc admin profile stop # 使⽤用 google pprof ⼯工具进⾏行行可视化展示 pprof -http=0.0.0.0:2222 ./profiling-10.189.33.60\:9000.pprof
28.杀⼿手锏
29.全⾯面了了解IO
30.全⾯面了了解 IO ● ● ● ● ● IO 流程 Buffered IO vs Direct IO Page Cache IO Scheduler 磁盘性能 ● 参数调优
31.
32.Block IO 流程http://www.ilinuxkernel.com/files/Linux.Generic.Block.Layer.pdf
33.Buffered IO vs Direct IO ● Buffered IO ● read (LRU) ● flush or writeback ● Direct IO ● O_DIRECT ● Block Alignment ● WAL(write ahead log)https://medium.com/databasss/on-disk-io-part-1-flavours-of-io-8e1ace1de017
34.Page Cache ● Temporal Locality, recently accessed pages will be accessed again at some point in nearest future. ● Spatial Locality, the elements physically located nearby have a good chance of being located close to each other.
35.IO Scheduler ● IO Queue ●elevator:Deadline, CFQ, Noop ● how to # 查看 sda 的 scheduler cat /sys/block/sda/queue/scheduler # 设置 sdb 的 scheduler 为 noop 算法 echo noop > /sys/block/sdb/queue/scheduler
36.磁盘 ● 顺序读写快 ● 随机读写慢https://qph.fs.quoracdn.net/main-qimg-f0bf80ac2007d1f39e8851a5e25b870c
37.回顾两个问题 ● 之前的压测结果中，为什什么刚开始的⼀一段时间响应时间特别低？ ● 为什什么之后响应时间变⾼高？并且波动幅度很⼤大
38.参数调优 ● Virtual Memory ● /proc/sys/vm/dirty_ratio ● /proc/sys/vm/dirty_background_ratio ● /proc/sys/vm/dirty_writeback_centisecs ● /proc/sys/vm/dirty_expire_centisecs ● IO ● cat /sys/block/sda/queue/scheduler ● /sys/block/sda/queue/read_ahead_kb ● nr_requests ● max_sectors_kb
39.深度优化 Minio
40.再回顾 MINIO 写流程 ● 随机写 ● 写次数放⼤大
41.优化⽅方案 — ⼩小⽂文件合并⼤大⽂文件 ● fallocate 预分配空间 ● 顺序写⼊入 ● ⼩小⽂文件的索引（volume id, offset, size）存 leveldb
42.FIO 测试效果 # 测试随机写性能 fio -name sequentialwrite -rw=write -bs=10k -runtime=100 -iodepth 128 -ioengine libaio -direct=1 --size=200G --randrepeat=1 \ --directory=/data10/fio --nrfiles=1 --openfiles=1 —group_reporting # 测试顺序写性能 fio -name randomwrite -rw=randwrite -bs=10k -runtime=100 -iodepth 128 -ioengine libaio \ \ -direct=1 --size=200G --randrepeat=1 \ --directory=/data10/fio --nrfiles=1 --openfiles=1 --group_reporting
43.再谈 Golang IO ● 不不同 IO 介质之间数据互传 ● req.Body ● *os.File ● io.Copy
44.性能压测 12 个节点，每个节点 12 块盘，写 64KB
45.测试读性能分析业务场景 ● 20% 数据为刚写⼊入，⼤大部分在 Page Cache 中 ● 80% 数据随机分布在硬盘上制定测试⽅方案 ● 利利⽤用 MINIO 消息机制，将所上传的对象的列列表写⼊入 kafka ● 写⼊入⼀一段时间之后，再根据 kafka 中的⽂文件列列表进⾏行行读压测
46.你猜性能如何？
47.性能⾼高的离谱！
48.事实本该如此 ● 因为数据顺序写⼊入，其⽂文件列列表发到kafka的时候也是顺序的，所以命中了了顺序读的策略略 ● 加⼊入随机因⼦子之后，读性能急剧下降，符合预期
49.再回顾 MINIO 读流程 ● 从 N 个节点上读取 meta 信息 ● ⾄至少从 N/2 个节点读取 data ● 每⼀一次读取的时间包括两个部分 ● ● 从 levelDB 读取索引 ● 从⼤大⽂文件中读取对应的数据并发读的最终时间取决于最⻓长的⼀一个
50.优化⽅方案 ● 将 Meta 信息压缩后直接存⼊入 levelDB, 减少⼀一组 IO ● 将 levelDB 存在性能更更⾼高的 SSD ● 降低单个 Set 的 Drive 数量量
51.压测结果 12 个节点，每个节点 12 块盘，混合读写 64KB
52.路路漫漫其修远兮 ● 如何解决尖峰问题 ● ⻓长时间压测，确保集群容量量很⼤大以后仍然可以保持不不错的性能 ● levelDB 是否适合这个场景？
53.总结
54.总结 ● 再回顾 MINIO ● 磨⼑刀不不误砍柴⼯工
55.谢谢

2.1 基于MINIO的对象存储方案在探探的实践 于乐

2.1 基于MINIO的对象存储方案在探探的实践于乐