对存储项目的一些看法

说明:

个人对存储项目的一些见解, 慢慢补充,完善,

存储项目特点:
极高的稳定性,
极高的可靠性, 可用性,
性能满足需求,
异常处理要有预案
测试相当重要, 要测试充分
需要试用/试运维后,方可以分布/上线
项目周期长



一个存储系统最主要的技术指标:

高可靠/高可用/灾备问题:
多备份, 多集群,多中心, 同步备份(强一致), 异步备份(弱一致?)
数据可靠性分级保证
    本地磁盘的损坏,用本地raid保证
    机器的损坏,用机器间的副本保证
    集群的损坏,可以考虑多异步备份保证数据的完整性




大容量/扩容问题:
1, 大容量指2方面:
    1, 存储系统能支持千亿级别的文件数量, 保持一定的性能,  
    2, 存储系统能支持大文件, 比如一个1PB的镜像文件,同时本地文件系统在镜像文件上的选型也很关键
    3, 存储总容量, 存储总容量能到PB级

2, 扩容
    在同个集群内扩容的风险(包括数据的平衡分布, 数据的大量迁移, 总文件数是否扩大等), 能支持的极限,扩容的方案, 能否同时提高性能等
    跨集群, 多个集群组成一个集群组,  对外提供统一的名字空间, 能否支持跨集群扩容
    跨集群扩容, 尽量不能有数据迁移, 同时必须考虑单点瓶颈, 至少要保证扩容不能影响业务.
   
    

性能优化:
主要的办法可以参考底层文件系统来做优化

1, 找瓶颈, 查看系统状态, 排除干扰等办法

2, 如果在硬件如cpu, 网络, 硬盘, 内存等都没有瓶颈的时候, 但是io性能确不高, 这个时候
主要来自软件的瓶颈, 说明存储软件在io路径中, 不能合理的利用硬件资源而限制了IO性能

2, 硬件瓶颈, 如果是cpu/网络/硬盘/内存等存储瓶颈, 这是比较常见的,
 一般来说这个时候可以用改进方案的办法处理(提升硬件),
还可以加一些特性/优化软件, 减少对硬件的访问压力, 如磁盘缓冲,inode缓存等.
也可以根据硬件的特点, 提高硬件的利用率, 比如对磁盘的随机写用日记转换为顺序写, 使用预读策略等.
硬件的瓶颈同时可以考虑扩展, 但是要确认扩展确实能提高性能, 考虑其性价比.

3, 优化部署方案, 调整性能参数, 等对性能都会有比较大的影响.

4, 是否存在单点瓶颈, 影响系统性能
 

稳定性问题:
充分测试, 代码改动审核, 试用, 试运营, 多备份


异常处理:
对于异常, 要有处理预案,

运维监控:
有力的运维工具
监控到位, 能发现潜在问题, 在问题爆发前发现并处理



一个存储项目的周期:

现在存储项目都是使用开源方案, 开源方案可以认为是个初步成熟的系统, 选择方案后,
经过架构研究/设计

1, 明确需求
使用场景
容量, 扩容, 多中心, 高可靠,高可用,性能指标

2, 方案评估/选择
选择项目主要软件(选型),研究/比较多种方案, 选择一种能满足需求的方案,
这个阶段难度比较高,需要结合人力/资源/需求/方案特点等多种因素综合考虑
选择一个最合适的方案,合适的方案不一定是最优的方案.

3, 架构研究/设计
方案深入研究,
架构设计, 模块化设计, 模块接口设计等

4, 具体实现
模块实现, 系统测试/验证/调试等,系统初步可以工作

5, 部署/测试/优化/问题处理等
确定方案部署策略, 部署并试用,
 基本能满足要求, 维护比较吃力,  只能做测试系统和demo, 不能正式上线
需要做测试系统(稳定性, 异常, 性能)等, 试用系统,提供实际场景的测试并能试用
问题处理, 细节改进/优化, 稳定/性能提升, 异常处理能力提升, 完善维护工具, 完善监控等, 需要测试验证
主要关注把控能力, 优化,改进

6, 系统试用&问题处理
系统试用,长时间试用,足够稳定后方可评估上线, 主要关注稳定性.

7, 发布评估/上线评估
在经过优化,充分测试, 长时间稳定试用后, 可以认为这是个相对成熟的存储系统
可以达到发布/上线要求就可以发布/上线

8, 后期维护/改进
问题处理, 性能提升, 特性需求等

9, 成熟阶段
在经过一段长时间的运营,系统成熟稳定后,
这个时候应该尽量避免存储系统的任何改动.
如果需要引入新特性, 一定要经过长时间的测试, 试运营(新集群当做备份集群),
或者先在一些不重要的场合试运行, 等足够稳定后再使用

常用管理工具:
项目/bug管理/ 案例共享:    禅道管理, redmine

代码管控:                        git, svn
代码review:                     reviewboard
源码解读/知识分享:        web+svn/git?