国内存储界现在是百花齐放,非常热闹。软件定义存储,云存储,超融合等各种创新企业也在各自领域快速的发展。关于各方面的概念解释和技术分析很多,但是我感觉关于存储系统的开发方面,实践性的文章非常少。我就据自己多年的存储开发经验,写几条原则,希望能抛砖引玉,让各位开发人员和架构师能进行更广泛的讨论。
1. 重视元数据的冗余安全。很多人说存储的稳定性是***位的,其实任何人为的系统都是有可能出错的,存储的数据安全性才是***位的。出错不可避免,宕机不可避免,任何软件都是有bug的,但是一定要避免出错后数据丢失,特别是元数据丢失,要把这个概率降到******。所以,设计元数据方案就像造飞机一样,要有2套以上的独立冗余方案。这个是架构师***个要考虑的问题。
2. 产品有定位,功能有取舍,要简单突出。存储的稳定性非常关键,复杂的东西很难稳定,除非不计成本。所以,我们首先要清楚产品的定位和市场应用,针对这个定位和市场应用来设计开发,其他的辅助功能一定建立在这个基础之上。如果一个产品开始设计的时候就考虑到了很多功能都要做到***,那么很有可能主要的架构设计复杂,影响稳定性,***影响最主要的功能点。所以,研发要对产品部门和销售部门的要求有取舍,并且一定要坚持,这个在设计中非常关键。
3. 抽象,抽象,再抽象。其实这个和上一条的简单原则有关系,抽象了,那么架构就会非常简单。模块之间的耦合度就低,这个其实是软件开发的共性。存储软件的基础架构其实是和协议,和OS,和硬件驱动都是无关的。如果相关了,那么这个架构一定出了问题。
4. 数据驱动,不是功能驱动。这个可以参考linux内核设计,内核负责功能机制,但是用户态负责数据驱动来做出各种应用。应用一定是和数据相关而不是和功能相关的,功能是非常共性的东西,由上层的数据来决定了具体的应用。
5. 我们能碰到的所有的问题都是别人解决过的问题,碰到架构或者其他方面的问题参考现有的linux内核架构,block/scsi中间层,各种协议,看看他们是如何解决的,参考这些业界标准基本不会出错。发明创造是科学家的工作,不是工程师的工作。
6. Debug系统做好了,产品就不会做不好。这个是软件开发的共性,不用多费笔墨。只是存储开发有两个问题debug起来非常难,一个是一致性问题,一个是性能问题。由于它的难度和全局影响性,这两个debug系统***要由系统架构师亲自设计甚至编写。
7. 适当打补丁,但是***要勇于承认架构有问题,要勇于重新来过,长痛不如短痛。真正稳定的软件是不会一版成功的。
【编者按】
向程序员致敬!
作者介绍:江松,Storwind创始人,具有超过16年的国内外企业级存储系统研发经验。Storwind专注于软件定义存储,相继研发和发布了LeadIO SSD缓存加速软件,IPSAN/NAS软件,商业级软RAID, 对象存储和云存储网关Cloudstation,获得了众多合作伙伴和客户的高度认可。
本文来源:微信公众号“乐生活与爱IT”