“给你几个硬盘，你能提供什么样的高可靠性存储解决方案？” 我们这些计算领域的工程师在面试时，常被问题这个问题。

这是一个很有意思的问题，十个人有十个答案。作为专业的从业者，如果停留在“配成RAID1或RAID6”之类，就显过于简单没有多少参考意义。我想借这个问题试着简单阐述一下在工作中我是如何分析存储问题的。

第一、基于统计数据分析具体场景的存储需求

首先，对于一个具体场景的存储解决方案，我们要了解这个方案的需要解决什么问题。我通常从以下五个维度作为切入口，统计分析生产环境中的真实存储需求。

（1)、协议：应用层应用读操作和写操作的协议
（2)、大小：应用层读操作和写操作的数据大小及基分布特征
（3)、数量：应用层读操作和写操作IOPS及基分布特征。
（4)、容量：未来2年内存储可能性增涨以及总容量的需求。
（5)、独特的痛点：这一类应用在存储需求上有什么和其它应用不一样的痛点。

其中第5点特别重要。这里列几个常见的存储痛点问题：
（1)、相同数据重复读操作的概率较高，但实际读操作的缓存命中率较低。
（2)、公有云环境中数万POD需要定期备份，偶尔需要读出数据进行系统恢复。
（3)、容器是无状态的，需要一个存储方案保存应用配置和运行状态
（4)、需要频繁从snapshot中恢复数据和应用。
（5)、小文件数量特别多。
（6)、每个月都有过万的SaaS服务POD需要同时升级，每个POD应用软件的大小合计超过100GB，导至很多IO问题 （然而每次版本的不到100M）。
（7)、某新型号硬盘，其季度故障率超过3%，数据丢失风险非常高。

第二、存储的冗余配置计划

存储的冗余配置其实是在如下四个彼此制约的兴趣点中，根据应用层的读写特点而选择的一个中庸的平衡方案。
（1)、最大可用容量。
（2)、最大读操作IO性能。
（3)、最大写操作IO性能。
（4)、数据安全。

以上这些指标又是由这如下三个实际的变量决定：
（1)、硬盘总数量
（2)、RAID的Stripe width
（3)、空盘数量。

在估算存储的大小时，估算因子中单个硬盘的IOPS应基于实际的I/O测试结果。我过去常常在RAID 10 的配置下，20%写入、80%读取、读写操作小于20 msec 毫秒的响应时间的场景中实际测试并计算单个硬盘的IOPS。

理论上来说，在没有读写合并/聚合操作的情况下，一个硬盘的最大IOPS可以按如下方式进行估算。
Max IOPS = 1/(avgSeek in ms + avgLatency in ms )
= 1/(avgSeek in half-turn in ms +avgLatency in ms)
= 1000 / (  (1/(DiskRPM/(60*1000)))/2 + 2  ).

例如一个7200转的硬盘，估算的IOPS是：
7200转的硬盘 IOPS = 1000/((1/(7200/(60*1000)))/2+2)
= 1000/(4.1667 + 2)
= 1000/(6.167)
= 162.2 IOPS

至于各类RAID配置的容量、读、写IO计算，Google一下有很有资料，我就不阐述了。

如果仅是单个服务器的内本地存储，正常情况下，配成RAID6也就满足的一般的需求。生产环境中的存储，常用的是RAID10和RAID50。各种冗余配置是根据实际应用层的需求来的。

当然，我们实际工作的存储配置计划设计，还会充分考虑到如下几个因素：
（1)、读操作的缓存命中率。
（2)、写操作I/O聚合因子。
（3)、最大网络端口吞吐量（MBPS）。
（4)、最大IB端口吞吐量。
（5)、最大FC端口吞吐量。
（6)、最大SAS卡吞吐量。
（7)、每个CPU的最大以太网/ FC读取操作（IOPS）。
（8)、每个CPU的最大以太网/ FC写入操作（IOPS）。

每个存储池中空盘数量和数据冗余配置还和硬盘故障率有关。一般情况下，硬盘故障率在1.2% - 1.65%之间。如果你的存储采用双倍冗余，而硬盘故障率大大超过3%，你则可以能需要在不换硬盘的条件下改成三倍冗余以提高企业重要数据的安全。

另外，在计算最终用户最大可用容量时，我们还需要考虑减去如下三类开销：

（1)、文件系统本身的metadata开销。
（2)、文件系统的性能销。例如，某些文件系统中的磁盘容量利用率超过一定比率时(比如，95％)，则I/O性能将快速下降。
（3)、预留给文件系统快照的数据空间。例如，在ZFS存储解决方案我们常将20%的空间预留给Snapshot。

第三、选择合适的文件系统和方案

当将统计分析出来的数据转化为基本的硬件需求后，接下来就是文件系统和对应的存储管理套件的选择了。你可以使用开源的方案，或闭源的方案，或各家公司推出的Storage Appliance。当下在公有云服务领域场景中，应该是各类Object storage和适用于软件定义存储的Block Storage技术最热了。

在有些领域，现有的方案可能解决不了你具体的痛点问题，这时可能要自己编写代码搞一个新的解决方案。

比如，在Oracle公有云中，我们有超过2.5万个SaaS的POD, 每个季度都要升级。每个POD的程序平均大约超过150GB。虽然每个版本的应用程序变更可能小于100MB，但原来每次升级时都要完整写入一百多GB的数据，导至很多IO性能问题。我们统计分析后，想能不能只升级变更的部分，同时又可以Rollback呢？后来，我们推出了一个基于内容寻址存储(CAS， Content-addressed storage)的SaaS应用程序升级解决方案，解决了这一问题。与传统的基于块的数据访问或基于文件的数据访问相比，CAS存储提供基于对象的数据访问。CAS存储的一个例子是git版本控制系统，它基本上是一个CAS存储的文件系统。

第四、存储的可靠性分析

在高可靠性这一问题上，我们通常是从以下六个维度来分析和改进存储服务方案的。

（1)、单点故障，包括硬件的各个组件、软件的各个进程、硬盘热拔插、坏盘是否会导致零I/O、Chatty Disk是否会导致零I/O、DISK Resilvering、系统启动盘、硬盘架(Enclosure)。
（2)、集群框架，包括单个储存节点的CRASH、HANG、PANIC、手动切换集群、手动集群Failback、集群的Split Brain、集群的heartbeat 故障、高负荷下的集群接管操作。
（3)、共享服务，如果有多条配置，则在DNS、NTP、AD、LDAP、NIS中添加或删除一个条目不应影响数据访问和管理接口的访问。
（4)、数据损坏，包括触发Split Brain并观察是否存在数据损坏问题并找出数据服务恢复的解决方案，触发RAID损坏并观察是否存在数据损坏问题并找出数据服务恢复的方案。
（5)、基础架构服务故障。
（6)、管理和监控接口的可靠性。

当然，一个完整可靠的存储解决方案还需要考虑软件和固件的各种初始设置、升级和回滚，网络、存储和系统管理的基本配置，客户端集成，性能，压力，安全，具体功能，和相应应用的集成，以及监控等等方面。

本文旨在简单阐述一下作为一个IT系统架构师，我过去工作中如何分析大型数据中心发生的存储问题的。其中有些观点不一定正确，欢迎批评指正。

欢迎大家发表留言，列出你在存储领域遭遇到的痛点问题。

（作者：王录华，Oracle云服务研发总监）