有关存储一些问题的开放讨论

spook

在底层做的 分布式文件系统， 以前 EMC的XTO搞得，被 IBM 买了，上层界面还是 和 其他一样。

如果有 SVC 可以考虑用SVC 做strip ，把数据分散到 各个 阵列上去， 然后由阵列的再去做。貌似用的是负载均衡的方式。

还有，楼主既然是大数据连续读写 ， 考虑过 Raid3 没有

liaoboda

原帖由 spook 于 2008-10-16 11:33 发表
在底层做的 分布式文件系统， 以前 EMC的XTO搞得，被 IBM 买了，上层界面还是 和 其他一样。

如果有 SVC 可以考虑用SVC 做strip ，把数据分散到 各个 阵列上去， 然后由阵列的再去做。貌似用的是负载均衡的方 ...

没有，其实Raid内部的情况我真的不是太清楚，买了本冬瓜的书在看。我们现在准备用SSD Rambox解决比较棘手的问题。可能会上100到200T。整个的考虑用lustre，当然基础的硬盘理论，和一些基本的测试和调整对整个性能的提高会有很大的帮助的。
另外我们的应用有很多，有大量7M的文件（每个单元100万个以上）每天6T到7T的数据产出的处理。 集群运算对大文件顺序读写。对少量百兆级别的文件的读取写入。大规模数据转移。等等。比较复杂，所以分很多部分。那些大量小文件我们开始考虑SSD 和rambooks了。现在百度和巨人每个季度都采购上千万的这个东东，这个是以后的方向。

storm the front

SSD 和rambooks这2个东西不是才出来不久吗,你亲眼见过百度和巨人的机房里在用这个?

liaoboda

原帖由 storm the front 于 2008-10-16 15:48 发表
SSD 和rambooks这2个东西不是才出来不久吗,你亲眼见过百度和巨人的机房里在用这个?

ssd我见过对百度出货。

spook

前一段时间有新闻……

spook

我们这么算，假设一个硬盘 32M Cache，至少保证1/4 用来读 ，至少保证1/4用来写，那么就是有 8MB的大小；假设一个 块 如果是 64K，一共至少有128 个块 在Cache中。按照一半一半的原则， 4MB的文件可以称为中文件，64K × 16 =1MB，可以称为小文件，小于64K的文件就算 碎片文件了。8M下的文件可以算是大文件。超过8M的文件就可以认为是特大文件了。

不知道现在阵列底层的 文件系统是按照 块 来处理还是会转化成 簇 来处理，貌似 簇最多也就4K， 那么块=簇=4k 性能会最佳？ 感觉很诡异…… 觉得应该不是按照簇来做，那么又是按照什么方法来读取了，这个涉及到iops数量和Cache缓存的问题……不太清楚

感觉来说 块 越大， 越节省 IOPS，但是会更多的浪费 磁盘Cache；不知道这个结论是不是错误的。

然后，到了阵列又变成什么样子，还想不出来……

冬瓜头

别的我不知道na全部使用4k作为管理单位。面对上层，不存在小于4k的单元。
iops和传输带宽存在一定关系式，这个在《大话存储》中都有总结，以及各种raid的性能分析，有表格。
关于磁盘cache是否浪费，这个无所谓浪费与否，肯定一点的是读cache会占用大部分的cache空间，而不是写cache。用于盘阵的时候，对于写io，有两个参数进行全面的bypass 磁盘的cache，具体请参阅大话存储。
如果想进一步了解到了盘阵是什么样子，请提出具体问题，我尽力而为，共同讨论。

spook

系统文件系统的block   阵列的 block 和 磁盘文件系统的block 之间应该怎么设置才好

原因啊……

liaoboda

今天我确定百度至少有1／3的搜索业务已经换成了ssd 部分目前在换Ramdisk

storm the front

block太大了浪费空间,尤其是碰到产生大量小文件的应用时

摆渡真是有钱