ppt of the 1st. CIOS by alibaba.com

1. 1

2. 这里讲的“存储”不只是传统意义上的专业存储设备。
一般意义上讲的“存储”，是指数据库用的专业存储设备，而现下的存储服务
器、云存储应用场景越来越多，此其一
在维护、优化方面来讲，管理存储也并不仅限于对存储本身的配置、调整，需
要结合应用甚至其他系统综合分析，此其二
2

3. 非常简单的单台服务器结构
3

4. 非常简单的单台服务器结构→多台服务器的集群
4

5. 数据库、各种功能增多、剥离，出现了独立的应用集群，与图片服务器共享数
据
（共享存储经历了PC-Server、PC+DAS、NAS的过程）
5

6. 前端负载 增加——增加了Cache层
6

7. 服务器数量多到一定的规模，出现File-Server，统一文件操作接口，避免过多
mount，还作为云存储的网关
7

8. 特点：
文件量众多，数以十亿计
并发访问大，10W+ connections
应用环境杂，项目多，文件共享需求多
要求低成本，高可靠
这个时候，各种各样的问题就出现了
8

9. 数据混合导致空间被耗尽，存储空间上限瓶颈：拆分目录
随单个目录文件数量爆满、子目录数爆满导致写失败
意的软链接是日后运维的地雷，存储迁移、数据拆分的隐患
存储性能瓶颈：scale-up/应用层面分卷 → 集群 → 云存储
9

10. 文件系统的组织：
业务规模小时，没有任何问题：随意创建目录、往一个目录中随意堆放文件……
规模扩大，积重难返：目录有上限（用满子目录限制、文件数限制导致无法新
建文件）
实例：cnfenjie001→ memberid_to_path 之后，cn/fe/nj/… cn这个目录爆满
缓存的影响：例如随机小IO运行得非常好，出现了一个顺序大数据量IO的需求
，必然导致存储性能意料之外的表现——
中端存储一套，测试满足18000 IOPS，符合DB的需求，实际使用中发现IO影响慢
→Cache持续满→后端磁盘忙←发现实际使用中有另一个顺序读写定时跑；
NAS在搬迁时，磁盘利用率50%，两台NAS临时并到一台进行搬迁，发现元数据
存取缓慢；
FC→SATA copy备份数据，缓存被占满，导致FC IO响应缓慢
降级：GreenPlum集群，用SATA盘+ZFS的raidz2 ，初期非常顺利，第三年，SATA
盘故障率升高，业务增长导致IO负荷增加 → 每周坏盘
FS3，SATA实现了低廉的成本，唯一的问题就是坏盘后RTO非常长
10

11. 大图+分卷是主要目标，缩短文件路径是补充要求，但是最终缩短文件路径取得
了很好的成效
11

12. 12

13. 两个三位数的目录是以 id 做了某种取余数算法后得到的，避免目录分布不均匀
Nfs性能统计：access占比44% → 25%
13

14. 正常情况下，blade1挂FC磁盘，提供NFS服务，blade2挂SATA磁盘，不对外服务
，仅用于将blade1的数据复制备份，运行得非常好；
异常情况：blade2的SATA盘故障，①rebuild时间长达二十小时 ②data copy调
度运行 ③由于rebuild，导致copy拥塞 → block storage的控制器缓存被copy
的大数据流堵满，blade1的NFS服务异常缓慢，只能停止copy
14

15. 目标：大容量、低成本、可扩展的存储
场景：备份、数据集中营，非on-line需求
考虑过方案：LVM mirror、DRBD+multipath→LVM
教训：SATA降级IO慢，rebuild时间长、寿命有限
市场上类似产品：ONStor Pantera LS 2100
15

16. 16

17. 17

18. 18

19. 19

20. 数据布局的影响 主要是文件系统方面的效率问题，另外特定的设备如Netapp的
WAFL特性也是要注意的
硬件降级不仅限于SATA盘，还包括存储的控制器、电源等，不要看中端存储
+SSD盘就有了匹敌高端存储的性能，一旦出现硬件降级，中端存储的先天不足
就出现了。
20

21. 在项目还在需求调研阶段的时候，运维人员介入能够产生最佳效果，把运维的
思想与代码结合，产生最优的效果
但是实际操作中，往往到项目到了测试阶段或上线之前，运维人员才会得到消
息，此时，已经是箭在弦上，不得不发，离项目上线仅有10天？15天？不合理
的设计也不可能修改了
DB的存储基本上不会遇到这类问题。
21

22. 没有在方案设计之初介入，只有通过平时的积累+合适的机会推动改进。
与具体业务结合：
图片清晰化项目，同时完成产品数据拆分+路径改造——不是一提出来就会有人
有资源支持，功夫做在平时，机会来了成功率才高
Cache命中率统计：降低流量
22

23. 全球数据复制+同步的应用特点：会在当地扫描文件的元数据，元数据读写需要
的是内存，两台设备上的数据合成一台之后，内存相对“变小”了，导致磁盘
IO爆涨
23

24. 捕捉到Cache命中率下降→开accesslog→发现MISS特征
由此可见，开发代码的人并不关心运维，大多数人只是实现了自己想要的功能
就万事大吉了，没有运维的sense
24

25. 开发为了达到图片更新即可见的效果，专门做成 ?r=0.6438864282476 形式
取数据120Mbps→10Mbps，两台服务器，共节约流量220Mbps，NAS存储吞吐量
大约300多M，相当于存储性能提升了一倍多
发数据150Mbps→70Mbps，两台Cache服务器，共节约流量160Mbps，保守估计
带宽费用>10000RMB
25

26. 26

27. 27

28. 28

29. 有了SSD之后，存储厂商的日子比较难过；经历了开源+SSD替代小机+高端存储
的替换潮，虽然单机+SSD能够匹敌传统的高端存储性能，但由此带来的维护成
本是上升的：多机集群的可靠性、数据一致性、运维投入的人力……虽然不一定
是经济的选择，存在的意义在于：我们有、我们能。
开源+intel+SSD可以处理大多数互联网公司的需求
存储服务器的广泛应用，要求更加了解OS及OS的存储管理
人力成本低 → 重视CAPAX，忽视OPEX
29

30. 对云存储供应商的考查 → 对性能的评估 → 对运维方面的需求
OS如何更好地使用存储
30

31. 31

32. 32