最近学习Dell Compellent系列存储，做了一些笔记。
总体来说这个是一个企业存储，适合各种应用场景，不过，通过网上查一些资料，发现该系列存储白壁微瑕，总结下来主要在以下几个方面：
RAID Scrub（RAID纠错）
数据写入到磁盘过程中，或者存储在磁盘后有可能发生畸变。所以，所有的存储都会运行后台进程进行数据纠错。这就是RAID Scrub机制：控制器定期读磁盘数据块，利用检校数据检查磁盘数据块的正确性，如果发现数据块错误，存储将自动进行纠正。进行纠错的过程中，磁盘的读的IO将非常高。而Dell Compellent的RAID Scrub后台进程的运行优先级高于业务端，也就是说，无论业务多繁忙，都需要优先进行RAID Scrub。很多时候，业务IO请求和RAID Scrub进程会有冲突，这个时候业务IO的延时就会很大。而且，Dell Compellent的RAID Scrub进程的运行时间用户无法干预，这个是Dell Compellent性能表现不佳的重要原因。
数据分层（Data Progression）
数据分层是一个很好的提高性能的机制，但是Dell Compellent的数据分层也存在一个重要缺陷。启用按需（on-demand）分层策略后，当HDD的某些数据被主机大量访问，这些数据就会变成热点数据，热点数据块会被迁移到SSD，但是迁移过程中，主机端也在等待这些数据的访问结果，由于分层迁移的优先级高于业务端访问，主机端的访问只能等待迁移结束。
多路径机制
存储前端控制器多路径机制在一定程度上决定存储的读写性能和可靠性，现有的前端控制器多路径机制大致可分为A/A-S(Active/Acivie-Symmetric)、ALUA和A/P(Active/Passive)三大类。
A/A-S(Active/Acivie-Symmetric)机制，对于特定的LUN来说，在它的路径中，多个存储控制器的目标端口均处于主动/优化(Active/optimized)状态。多个控制器之间通过PCIe或Infiniband等实现高速互联的通讯，从主机侧发送一个IO到控制器端后，多个控制器可同时参与IO处理；存储系统会自动负载均衡，当一个控制器繁忙或业务压力较大时，存储系统不需要主机端多路径负载均衡软件参与就可以自动实现负载均衡。这种机制在高端存储中较多使用。
对于ALUA(Active/Active-Asymmetric)机制来说，特定的LUN在控制器的路径组中，只有一个控制器的目标端口组处于主动/优化(Active/Optimized)状态，其他控制器的目标端口组处于主动/非优化(Active/Unoptimized)状态。某个时刻一个特定LUN只属于某一个优选控制器，在多路径的配合下，IO从优选控制的IO组(Active/Optimized)下发IO，多路径不会发送该LUN的IO到其他控制器，一般通过将LUN A归属控制器A，将LUNB归属给控制器B实现两边的负载均衡，归属操作可以手动或自动完成。这种机制在中高端存储中使用。
还有一种是A/P(Active/Passive)机制，一般只用在低端双活存储阵列中。现在这种架构已经很少见了。对于特定的LUN来说，在对应存储的路径中只有一个控制器的目标端口处于主动/优化(Active/Optimized)状态，其他控制器的目标端口处于备用或平时不工作状态，其负载均衡处理方式与ALUA类似(即根据优选控制器来决定)，但是由于多路径和存储互不相识(多路径不知道那些路径是优选路径)，IO很难选到合适的路径，IO的下发可以说这完全取决于上层多路径的心情，解决方案是提供自研多路径来配合阵列选路，通过私有协议实现IO到优选路径的匹配。而Dell的Compellent就是使用该种机制，这也就带来了性能的问题。在一个4条路径的物理环境中，能够发现LUN的路径只有2条。
如果有一种情况：Compellent存储上的所有主机端口故障，但是控制器还继续工作，那么这个时候，属于该控制器的LUN将全部不能访问。因为这时候控制器正常，存储不会将LUN切换到另外的控制器。同时因为不支持ALUA机制，主机端也不能通过另外的控制器访问这些LUN。有个简单的办法就可以测试这种状况，就是把Compellent一个控制器上的主机端口线缆全部拔出。这个时候就有部分LUN不能访问。虽然这种情况比较少见，但是还是可能发生。
以上部分是通过网上查资料总结，本人没有条件论证，所以发布到网上，如果有不准确的请指正。
本文转自 川流信息 51CTO博客，原文链接:http://blog.51cto.com/tech4fei/2044898
