云存储将受制于驱动器可靠性和带宽

核心提示： 如果你使用5%这个值并除以365，那么你将得出每天的故障数量：将总带宽利用率小幅提高到7.5%的话，云存储将受制于驱动器可靠性和带宽(3)，将得到每天每个存储卷的故障数：迁移数据总量的故障下面得出的结论：当使用率为5%、存储容量为10PB的时候，每天平均你会有15个消费级SATA驱动器发生故障，

如果你使用5%这个值并除以365，那么你将得出每天的故障数量：

将总带宽利用率小幅提高到7.5%的话，将得到每天每个存储卷的故障数：

迁移数据总量的故障

下面得出的结论：当使用率为5%、存储容量为10PB的时候，每天平均你会有15个消费级SATA驱动器发生故障。在最好情况下，你大约需要24390 秒通过网络进行读取或者写入每个驱动器。你最多可以获得3.37个驱动器的全部带宽，24小时获得总共276 MB/s的带宽。因此，简单计算一下，276 MB/sec×3600×24得出每天的总MB/s。对于每个驱动器，你需要82 MB/s×24390×15个驱动器故障。以下是不同情况的计算结果：

任何负数意味着驱动器复制的要求超过了通道带宽。例如，在10PB、OC-48和5%驱动器使用率的情况下，带宽相当于6167659 MB(这超过了通道带宽)或者24小时内71 MB/s。显然，随着时间的推移，这个问题越来越明显，因为你复制数据的速度还赶不上丢失的速度。从统计概率上说，如果你有10PB的话，最终你将丢掉数据，而且不会用太长时间。唯一的架构选择就是保留数据的第三个副本，而这么做的成本很高。对于一个OC-48通道、使用率为5%的存储系统来说，拐点发生在5 PB～10 PB之间，在5 PB、使用率为7.5%的情况下，你只有42 MB/s的多余带宽(3652149，3600×24)。这时候就需要更高速的网络(付出更多成本)或者更可靠的存储(成本也不低)。

我相信云公司每天都在权衡着这些成本因素，找出什么是优化成本的最佳方法。有没有可能其中一些人并不了解基本的硬件问题?我当然希望不会是这种情况。显然，云存储适用于5PB、OC-48通达和消费级SATA存储。现在，有多少云是超过这个存储容量的?我不之道，但肯定是存在的，对于大型存储用户来说，多达10～20 PB的归档是很常见的。

云架构要比本地存储架构复杂得多。云存储可以设计成一个RAID后端，消除了很多问题，但是我所了解的大多数云由于成本因素而没有使用RAID。总的来说，云架构和云设计并不简单，对于大型数据卷来说，我看不出云比本地存储便宜多少。

驱动器可靠性和带宽将限制云的采用，而且这是一个可能永远也得不到解决的问题。带宽将越来越便宜，但是驱动器可靠性并没有多大改善，数据的增长速度仍将超过带宽。也许基于网络的重复数据删除功能会起到一些帮助作用——如果数据可以被重复数据删除的话。但是就目前来看，对于非常大型的数据存储来说，还没有一个比老式数据中心更好的选择。