【专家问答（翻译稿）】MCx揭秘

Oliver Ames谈到：新一代VNX MCx架构设计用于满足目前的一些颠覆性技术：云计算、多核应用、闪存技术等，这些技术允许业务应用实现更高的I/O流程。有些客户面对高标准的应用时，时常会问自己“我目前的存储系统，甚至DAS，能够满足应用程序在性能方面的要求吗？”，推荐参考下面的文章，你能从中找到任何关联性吗？

               http://talkincloud.com/emc-ceo-joe-tucci-cloud-is-most-disruptive-tech-wave-ever

               http://www.crn.com/news/cloud/229403082/emc-ceo-tucci-cloud-disruption-means-opportunity.htm

就我看来，客户在与其对手竞争的过程中，需要不断增强甚至加入新的应用来应对挑战，这种增长不断的对现有的IT基础架构施压，IT预算的大部分都被用于运维，而非创新。

最后一个链接来自已经使用新一代MCx架构的客户，如果能听到更多使用新一代VNX作为步入云计算的基石的例子那就太棒了。

http://www.emc.com/about/news/press/2013/20130904-03.htm

Allen.Ward问道：对热备用机制的重新设计，其背后的用意是什么？我知道这种变更的确有其好的地方，但我自己不是很买账，总感觉新的问题大于其优势，特别是像我这种控制欲很强的人。

我所能看到的优势有以下几点：

• 不需要预先定义和管理热备用
• 无需等待数据重构至被替换的盘
• 数据重构所带来的性能损失仅仅发生在首次热备用激活的情况下，因为不再需要数据回拷

但我的顾虑在于：

• 把潜在的热备用驱动器与等待被配置为Pool或RAID Group的盘混在一块儿，让我很难确定哪些盘可用于数据存储。
• 如果你已经计划好创建一个RAID Group，很有可能在你创建它之前，其中的一块盘已经被用作了hotspare，打乱了你原先的计划
• 考虑到资源平衡而特意构建的bus/DAE结构很有可能被新的热备用机制给打乱
• 我知道可以手动解放被选择作为热备用的驱动器，但仅限于CLI方式

我想知道更多背后的原因，使得设计者认为新的热备用机制所带来的优势会更明显。为什么不把新的热备用机制作为一种可选项，让用户有更多的选择。

Rainer_EMC回答： 我觉得最根本的原因就是对用户看起来更简单一些。客户不需要手动创建热备用，系统会帮你自动搞定这一切。

你依然可以配置热备用，也可以不配置，但必须指定热备用策略。不再需要从热备用盘回拷数据至新替换的磁盘，客户认为这部分I/O是多余的，应该能设计的更好一点来避免这种问题。如果你想回归原先的RAID组结构，可以使用copy back或物理移动该磁盘。我个人觉得新的做法更为自动化，系统会挑选最合适的盘做热备用。

dynamox问道：

• Unisphere Analzer性能计算器有增强吗？我特别关心FAST/FAST Cache是否能在更小的粒度上提供数据，比如LUN级别。我的客户问我，他们的LUN是否适用于FAST Cache，对于Pool LUN，我没法回答这个问题。比如，一个LUN收到100 I/O，有多少是FAST Cache处理的，多少是系统内存处理的，又有多少是磁盘处理的。

• 是否有机会提供更多强健的性能工具？

• 什么时候会发布R33的最佳实践文档？

nightcrawler086问道：什么时候才能开始支持Pool LUN的对称双活？

Rainer_EMC回答：这是一个关于产品路线图的问题，我建议你咨询本地EMC代表。

OllieAmes回答：

目前并没有对Unisphere Analyzer (UA)的计数器有任何更改，只能监控FAST Cache驱动器。一般来说，连续读写不适合FAST Cache，因为FAST Cache算法忽略数据流。FAST Cache设计用于处理随机小块I/O（读写）。而且，任何>=64KB的I/O都会被FAST Cache排除在外，由DRAM Cache处理。

老的FAST Cache (Classic FAST Cache)要求连续读写同一个block三次才会把数据提升至FAST Cache，因此不是所有的I/O类型都能收益于FAST Cache。但到了新一代VNX，Multicore FAST Cache能够让更多的RAID Group或Pool LUN受益，因为只要对数据块有一次访问（one time hit），它就会被提升值Multicore FAST Cache。这种提升有一个限制，那就是FAST Cache已用容量必须低于80%，一旦超过，又会回到以往的three times hit promotion。新一代VNX还采用了清理算法来释放FAST Cache从而更好的服务动态工作量（dynamic workload，意思就是有的应用I/O形态呈现出不规则性，某些热点数据可能过一段时间就变冷了）

这里有个演示演示FAST Cache是如何帮助解决这种情况的问题的：启动风暴

目前没有办法监控具体某个I/O是否被FAST Cache所处理，要确定一个LUN是否最能受益于FAST Cache，我们可以使用Unisphere Analyzer (UA)。监控LUN的访问形态，确定I/O的顺序或随机性，读或写。

注意：通过UA，你可以通过查看LUN的“FAST Cache Write Hits / Read Hits”，确认该LUN是否受益于FAST Cache，以及受益的程度。其它的计数器，比如"Read & Write Miss"、"Read & Write Ratio"可以很容易的帮助你理解目标LUN是否适合用于FAST Cache。

注意：以上计数器仅适用于RAID Group LUN，Pool，不适用于Pool LUN。

FAST Cache凭借其天生的“直觉性”，真正的缓解了管理员的调优工作。通过UA，你可以实时分析或者分析归档后的性能日志。

对于使用VMware作为Hypervisor的客户，可以选择购买vCOP (vCenter Operations) 以及EMC SRM (Storage Resource Management)。这里给你另一个连接是关于EMC SRM的。

很可惜的是，最佳实践文档尚未发布，但我相信不久以后你会看到的。