本文作者Henry Newman是是一位资深的行业咨询师，在高性能计算和存储领域拥有28年的行业经验。
现在几乎每天都有一个或大或小的公司发布新的云存储产品，不过事实是在企业防火墙外，云存储的潜力有限。
有两个原因导致了这种情况：带宽限制，商品驱动器带来的数据完整性问题，而许多云服务采用的是商品驱动器。这两个问题将限制企业数据存储用户在外部云上所能做的事情。
云所面临的挑战
理想的云存储具有如下特点：自我管理，自我平衡，自我复制，定期的数据校验以检查各种存储技术未发现的或误纠正的错误率。云存储需要托管文件有多个副本，并定期进行校验和确认，同时出于安全考虑需要将数据分布在各个存储上。
这是一个很好的想法，但是它面临着一些问题，比如可靠性，安全性，数据完整性，电能，复制时间和成本。但是其中一个最大的问题是硬件故障。磁盘和磁带驱动器有两种方式的故障：
l 媒介的硬错误率-- 一个错误发生前的平均比特数
l 设备年化故障率（AFR）--根据设备使用小时数
最常见的错误类型是厂商的比特错误率。比特错误率是指预计故障/比特数。下面是厂商通常发布的错误率信息：
|
设备 |
硬错误率（比特数） |
|
消费者SATA 驱动器 |
1 / 10E14 |
|
企业级SATA驱动器 |
1 / 10E15 |
|
企业级FC（光纤通道）/SAS驱动器 |
1 / 10E16 |
|
LTO（线性开放协议）磁带 |
1 / 10E17 |
|
T10000B磁带 |
1 / 10E19 |
这些数值看起来好像很好，不过我们需要注意到在过去10年的时间中，这些数值基本上没有太大变化，只改变了一个数量级，而存储密度则发生了巨大的变化，同时存储介质的性能也有很大的发展。随着未来缺口越来越大，问题将开始出现。如果使用厂商在最佳情况下的数值，那么一定数量的数据迁移将带来多少错误，复制需要多少时间？
|
数据迁移错误数 |
1PB |
10PB |
40PB |
100PB |
|
1TB消费者SATA |
9.007 |
90.07 |
360.288 |
900.720 |
|
1TB企业级 SATA |
0.901 |
9.007 |
36.029 |
90.072 |
|
600GB FC/SAS |
0.090 |
0.901 |
3.603 |
9.007 |
|
LTO-4/TS1130 |
0.009 |
0.090 |
0.360 |
0.901 |
|
T10000B |
0.000 |
0.001 |
0.004 |
0.009 |
很明显，甚至在1TB企业级驱动器上迁移100PB数据都有可能带来严重的数据损失。我所熟悉的许多云厂商甚至不使用RAID（独立磁盘冗余阵列）或通过镜像来保持数据安全。记住，前面数据反映的是理想的世界，不包括通道错误，记忆体故障和所有其他类型的硬件故障和无记载数据损坏。那么在不理想的世界下，而且在其他故障率比较明显的情况下，事情会怎么样呢？
|
数据迁移错误数 |
1PB |
10PB |
40PB |
100PB |
|
1TB消费者SATA |
90.072 |
900.720 |
3602.880 |
9007.199 |
|
1TB企业级 SATA |
9.007 |
90.072 |
360.288 |
900.720 |
|
600GB FC/SAS |
0.901 |
9.007 |
36.029 |
90.072 |
|
LTO-4/TS1130 |
0.090 |
0.901 |
3.603 |
9.007 |
|
T10000B |
0.001 |
0.009 |
0.036 |
0.090 |
在现有技术下，你可能会丢失900TB的数据，这可不是一个小数目，要复制这些数据也需要很长的时间。
带宽限制了复制
现在让我们来看看不同互联网连接速度和数据量下的复制时间。
|
网络 |
数据速率 |
复制1PB所需要的天数 |
复制10PB所需要的天数 |
复制40PB所需要的天数 |
复制100PB所需要的天数 |
|
OC-3 |
155 Mb/秒 |
802 |
8018 |
32071 |
80178 |
|
OC-12 |
622 Mb/秒 |
200 |
1998 |
7992 |
19980 |
|
OC-48 |
2.5 Gb/秒 |
51 |
506 |
2023 |
5057 |
|
OC-192 |
10 Gb/秒 |
13 |
126 |
506 |
1264 |
|
OC-384 |
19.9 Gb/秒 |
6 |
63 |
253 |
632 |
|
OC-768 |
39.8 Gb/秒 |
3 |
32 |
126 |
316 |
很明显，没有人有OC-768的连接，也不会有人很快有这样的网络。很少有人需要将100PB数据复制到一个云，不过问题是数据密度的增长速度超过了网络速度的提升速度。已经有人在讨论100PB归档，但是他们还没有讨论OC-384网络。如果发生灾难，在OC-384网络下复制100PB数据需要超过1年的时间，但是谁能够支付得起OC-384的费用呢？因此在可预见的未来，至少最大规模的企业级存储环境将需要一个集中化的灾难恢复站点以供存储运行恢复前之用。
消费者设备的问题也将迫在眉睫
不止企业会碰到带宽问题。在未来一两年内，我们中的大多数人将拥有10Gb/秒网络连接（见《10GbE（10Gb/秒以太网）价格的下滑对光纤通道来说是不利消息》）。目前互联网最快的骨干连接是OC-768，而我们许多人将拥有相当于OC-768的6.5%带宽的连接。当然，这还受到我们的DSL（数字用户线路）和有线连接的限制，但是它们的性能将增加并将耗尽骨干带宽。想一下我们要创造多少数据，迁移这些数据需要花多少时间，你会感到很震惊。我有一个家庭互联网备份服务，在家里有1TB数据。我花了三个月时间才将所有这些数据通过我的有线宽带离站复制出去。我的带宽就是我的瓶颈。如果我在创建离站副本前就遇到故障，那我将丢失数据。
Internet2等组织致力于缓解这个问题，但我担心我们创建数据的速度超过了我们可以迁移它们的速度。当数据丢失--比如说人为错误，自然灾难等--且必须重新复制的时候，问题就很严重了。如果你将所有数据放在一个云里面，而且在两个不同地点保存有两个副本，那么如果其中一个副本发生问题，你就需要从另一个副本中恢复它，你可以看到，这需要花很长的时间。在这段时间里，你可能只有一个副本。考虑到硬错误率，你将面临很大的风险。你可以有两个以上的副本--这可能是一个很好的想法，尤其是如果是任务关键型数据的话--不过这种做法的成本很高。
谷歌、雅虎和其他搜索引擎多使用云方法来存储数据，但是对于那些已经有10PB、20PB、40PB或更多存储数据且不经常使用数据的归档站点来说，是否有这个必要呢？现在有很多这样的站点，比如说存储医疗数据的站点、医疗影像或基因数据的站点、保存大型图片（比如说气象站点）的站点、保存石油天然气勘探所使用的地震数据的站点，当然，还有萨班斯-奥克斯利法案（Sarbanes-Oxley）要求美国公司保存的数据。将所有数据放到网上保存是否值得？很可能是不值得，数据规模和电力成本有可能成为很大的问题。
