EMC cmx950 和IBM DS8100 性能哪一个更好一点

piner

现在已经是规则之争了。

HDS从香港过来一个工程师，在仔细分析我们的规划后，认为我们的规划方式有问题，应当从访问规则1变为访问规则2：
如图

piner

访问规则1是，这个存储上，不同的主机都可以看到所有的RAID组，比如3个主机，则分为3个lun，每个主机访问其中一个，这样最大的好处就是，每个主机可以充分的利用到所有的磁盘资源，当其中一个主机不忙的时候，另外的主机可以充分利用资源。\r\n\r\n访问规则2是，每个主机都有自己的单独的磁盘，互相不干涉\r\n\r\n\r\nHDS的人主要认为，一个RAID组给三个不同的库访问，三个库可能互相干涉，互相有影响\r\n\r\n但是，我认为，因为存储层接收数据，本来就是非常刁钻的离散数据，是主机无关性的，你怎么改变，存储也是收到的是离散数据，如果改变成规则2，可能压力会更大。

piner

后来联系EMC的工程师，讨论他们的存储的规划，谈到这个问题时，EMC给我连线了好几个他们的专家，都是主张规则1，起码在EMC中，他们是主张规则1。\r\n\r\n问题是我们的数据真的非常离散，EMC的专家也承认，如果10%以下的命中率（128G的cache，1T的合计数据量），是一个很恐怖的现象，因此，他们将派专家组来配合我做联合测试。\r\n\r\n现在已经演变成EMC与HDS的性能大战，名誉之争。

biti_rainy

呵呵，nnd ，就等你们先上 EMC 。等了半年，结果我们却先上了……还要让我去接受 AIX5305与powerpath 5.0 的风险。\r\n\r\n其实这里我想大家过度强调3个数据库了，作为存储厂家来讲，你就当3个数据库就是一个 数据库应用，总之现在iops 就这么多，到底是否有办法。\r\n\r\n如果争论3个库还是1个库的问题，那是不是可以说明，当一个库  iops 达到17000并且磁盘只有240 的时候，就必须选择更换规则？\r\n当然，事实情况，如果你选择了规则二 ，效果不好，他们又会说你早该选择规则一。 呵呵，这种事情就这样的，所谓优化是一门艺术，艺术的意思，就是无定则，而已。

orian

如果是ibm的规则，分散开比较好，大家共用所有的磁盘，增加（其实是减少）平均等待时间，因为ibm cache slot可以做得比较小，cache效率高一些。\r\n\r\n如果是hds规则，看来还是集中起来好一些，干脆丢弃一些数据，反正也不会命中，不要徒劳去占据cache了。如果可能，在同一台机器再次进行一些数据访问频度的检查，把某些特定的表空间（lv）用特定的方式保存，例如有的做stripe，有的不做。\r\n\r\n可以用filemon收数据好好看看，甚至用trace

piner

最初由 orian 发布\r\n[B]如果是ibm的规则，分散开比较好，大家共用所有的磁盘，增加（其实是减少）平均等待时间，因为ibm cache slot可以做得比较小，cache效率高一些。\r\n\r\n如果是hds规则，看来还是集中起来好一些，干脆丢弃一些数据，反正也不会命中，不要徒劳去占据cache了。如果可能，在同一台机器再次进行一些数据访问频度的检查，把某些特定的表空间（lv）用特定的方式保存，例如有的做stripe，有的不做。\r\n\r\n可以用filemon收数据好好看看，甚至用trace [/B]

\r\n\r\n\r\n这个东西，就很扯了，在先用这个存储之前，还要先必须详细的了解这个存储的运行规则。\r\n\r\n\r\n我们是做技术的，当然好理解了，人家很多公司，不是做技术的，那不完了。\r\n\r\n存储应当尽量的让用户简单，最简单的就是每块硬盘收到同样多的IOPS。\r\n\r\n\r\n另外一个问题，集中不集中，也是相对而论，就算我一个数据库，只访问自己的raid组，就算集中，不一定啊，因为上层来的数据，根本不管你怎么放，它就是随机的。\r\n\r\n\r\n想象一下分子的运动吧，没有办法知道哪个时刻这个分子在哪里的

biti_rainy

最初由 orian 发布\r\n[B]如果是ibm的规则，分散开比较好，大家共用所有的磁盘，增加（其实是减少）平均等待时间，因为ibm cache slot可以做得比较小，cache效率高一些。\r\n\r\n如果是hds规则，看来还是集中起来好一些，干脆丢弃一些数据，反正也不会命中，不要徒劳去占据cache了。如果可能，在同一台机器再次进行一些数据访问频度的检查，把某些特定的表空间（lv）用特定的方式保存，例如有的做stripe，有的不做。\r\n\r\n可以用filemon收数据好好看看，甚至用trace [/B]

\r\n\r\n那你一定要根据数据生命周期来管理了。\r\n\r\n 因为不同时期，热点数据一定不一样。 而规划总也赶不上变化（比如新增加的表、新近搞的活动、新的访问比较频繁的应用上线），我就曾经遇见过这样的情况，一开始规划好的，但是后来存储资源总是有限的，所有预留的都会被使用上，并且背离了先前的初衷。当然如果系统表空间一创建好一年半年的不发生变化还好。但我们是经常变化的，并且往往很多调整，都不是随时可以做的， 这给管理和维护也带来难题。在我们的数据库系统中，哪种问题出现的故障次数最多？ 两种变更： 1，数据库schema变更。 2，加数据文件。 有些人无法理解加数据文件是一个高风险的操作，包括我们team新来的人，但很快他就明白了。\r\n\r\n所以又进化到 ILM 了，哈哈。 但在高压力的系统中，ILM 表现如何，现实吗？  什么时候能实现？ 要定义某个凌晨时分去迁移数据么，评估迁移多长时间以及为其所付出的cost， 很难说的。

orian

另外一个比较简单的解决办法是可以再增加磁盘，把别的系统业并进来，依然按照你们最开始的方式规划，把系统跨越所有的组。让128G（甚至更少的cache）只是用来做写cache，读数据完全靠裸盘iops去拼。\r\n\r\nILM通常是用来降低成本的，不太适合在系统压力大的时候考虑过多ILM，只有做数据访问分析还有用，看看数据是如何读写，特点如何等等，了解清楚了做规划。\r\n\r\n以前系统设计考虑tpcc之类比较多，现在越来越多考虑磁盘。提高存储性能的方法基本上都很费钱，如你们现在的情况，可以要求厂商提供cache不命中情况下裸磁盘的iops，看看是不是就是这个量，如果是，也就没什么“优化”余地，只能牺牲一些，提高另一些的速度。\r\n\r\n有一些工具也可以用一下。其实filemon就很好用，把buffer开大，把跟踪数据时间减少，防止出现data trunked，也基本上没有严重的性能干扰（时间要少，几秒钟吧。）\r\nfilemon -o /tmp/filemon.out -O all -T 2048000 ; sleep 5; trcstop\r\n然后看看/tmp/filemon.out的内容，如果方便，就贴出来，大家一起研究一下。如果提示data truncked，把-T的参数再加大，直到没有这个提示，但注意系统内存情况。一点一点加

piner

最初由 orian 发布\r\n[B]另外一个比较简单的解决办法是可以再增加磁盘，把别的系统业并进来，依然按照你们最开始的方式规划，把系统跨越所有的组。让128G（甚至更少的cache）只是用来做写cache，读数据完全靠裸盘iops去拼。\r\n\r\nILM通常是用来降低成本的，不太适合在系统压力大的时候考虑过多ILM，只有做数据访问分析还有用，看看数据是如何读写，特点如何等等，了解清楚了做规划。\r\n\r\n以前系统设计考虑tpcc之类比较多，现在越来越多考虑磁盘。提高存储性能的方法基本上都很费钱，如你们现在的情况，可以要求厂商提供cache不命中情况下裸磁盘的iops，看看是不是就是这个量，如果是，也就没什么“优化”余地，只能牺牲一些，提高另一些的速度。\r\n\r\n有一些工具也可以用一下。其实filemon就很好用，把buffer开大，把跟踪数据时间减少，防止出现data trunked，也基本上没有严重的性能干扰（时间要少，几秒钟吧。）\r\nfilemon -o /tmp/filemon.out -O all -T 2048000 ; sleep 5; trcstop\r\n然后看看/tmp/filemon.out的内容，如果方便，就贴出来，大家一起研究一下。如果提示data truncked，把-T的参数再加大，直到没有这个提示，但注意系统内存情况。一点一点加 [/B]

\r\n\r\n在我的blog中，我已经把每块盘的iops计算出来了，而且，从存储的监控软件上也可以看到这些数据。\r\n\r\n系统出现瓶颈的时候，那个香港人说存储也是不忙的，没有热点，但是就是不行了，他就只能说我们的规划方式有问题。\r\n\r\n至于用filemon，我们是不可停的系统，何来调整buffer一说。

orian

sorry, 我说得不清楚，造成楼上理解错误，我的意思是指filemon程序本身用的buffer\r\n他做数据访问跟踪需要用一块内存保存临时数据，如果buffer不够会出现buffer回绕，收集的数据不准确，所以要增大buffer, filemon -T参数带的\r\n\r\nhttp://www.unet.univie.ac.at/aix/cmds/aixcmds2/filemon.htm\r\n\r\n我明天仔细看看你的blog，没有争论谁对谁错，或者必须选择什么方案、技术的意思，只是觉得这个case很典型，可以深入研究一下。既然你们已经在数据库层做到极致，剩下的也只能在操作系统和存储上想办法了。当然，我知道如果能在越高层解决，效果越好。\r\n\r\nILM也并不是一种技术，或一件事情，ILM我觉得最重要的是数据访问分析，存储使用分析，至于以后的数据分离，数据迁移，归档等等，都要以数据访问情况为基准，到底是用什么方式，是否分离、迁移，完全要看分析的结果。也可能ILM一词已经完成其历史使命，该用新的词了，现在流行什么：information governance....哈哈，当然，噱头居多。