本文列举了造成CLARiiON SP使用率较高的一些可能的原因，并列出了对应的解决办法

·         由于过高的SP使用率导致NDU (Non-disruptive Upgrade)操作失败

·         Navisphere Analyzer显示SP使用率超过50%

·         SP间歇性无法管理，执行Navisphere CLI命令会返回超时错误

除了主机I/O，还有许多其他因素造成SP利用率的升高，包括：

·         强制刷新写缓存(Write Cache)

·         有大量的CLARiiON对象(LUN、磁盘和已注册的Initiator等)需要管理

·         与传统的LUN相比，存储池(Storage Pool)或虚拟资源分配(Virtual Provisioning)需要更多的CPU运算周期。新增的一些Pool的功能，如Thin LUN、压缩(Compression)和全自动存储分层(FAST VP)同样会显著增加SP使用率

·         复杂(混合)的MetaLUN。MetaLUN中的每个组件(component) LUN都会被SP监控和管理，因此大量的LUN被串联(concatenated)和条带化(striped)在一起后会造成更多的管理开销。

·         大量被管理的主机

·         ESRS抓取存储信息

·         Navisphere CLI脚本

·         多个Navisphere Manager进程同时运行

·         正在进行LUN的扩容(expansion)或迁移(migration)

·         当创建新的Pool或LUN时，后台置零(Background Zeroing, BZR)操作会对SP使用率造成较大的影响。以Pool为例，磁盘会被分割成私有private LUN以供Pool LUN使用，一旦这些磁盘被加到Pool中后，BZR进程就会启动

·         后台校验(Background Verifies, 特别是ASAP优先级)，LUN捆绑(bind)或正在重建(rebuild) RAID

·         在Vault磁盘上(CLARiiON是0_0_0至0_0_4磁盘，VNX是0_0_0至0_0_3)捆绑了用户LUN产生的大量I/O造成的高响应时间

·         复制类软件如SnapView

·         Clone、SnapView、MetaLUN中的磁头竞争(linked contention)问题

·         SP使用率超过50%并不一定是问题，但如果使用率达到了100%则存储响应时间会成倍增加。必须牢记的是对一个高可用的系统来说，每个SP都要求能独自处理所有的主机I/O以应付故障发生时的情形。假如仅有一个SP在工作(同时写缓存也被禁用)会造成重要应用访问超时，那这样的配置不能被认为是一个完全冗余的系统。非中断升级(NDU)同样要求两个SP的平均使用率在50%以下，通常在系统高峰时无法完成升级。

为了降低SP使用率并且改善Navisphere/Unisphere的影响时间，可以采取以下操作：

     

·         尽可能从Vault磁盘(0_0_0至0_0_4)迁出用户LUN

·         如果为了NDU升级需要临时减少SP使用率，可以关闭部分非关键业务的主机

·         CX3系列存储可以升级到Release 26 Patch 29或之后版本以支持Navisphere的差异轮询(Delta Polling)功能。由于Navisphere每次仅抓取上一次抓取后更改的数据，这将减少总的SP CPU使用率并改善系统响应时间。在存有大量LUN、MetaLUN和硬盘数的配置上效果最明显

·         CX4的所有FLARE版本都带有差异轮询功能因此普遍地Navisphere/Unisphere的响应时间要比早期设备要快

·         在创建Storage Pool和LUN之后，等待Background Zeroing完成后再引入I/O密集型应用到存储中

·         减少Navisphere Manager进程数量。类似EMC ControlCenter、EMC Replication Manager之类的外部程序会定期抓取存储系统信息从而增加SP使用率，可以考虑在NDU 操作前关闭它们

·         如果可能，合并部分LUN以减少它们的数量。如果一个RAID group上的多个LUN被同一台主机的同一个应用使用，有可能会造成磁头竞争(linked contention)、更大的寻道距离以及更低的缓存使用率。将这些LUN迁移至数量更小、容量更大的LUN同样可以减少需要监控的统计量从而进一步降低SP使用率

·         禁用Navisphere的自动管理主机(auto-manage hosts)功能以减少Navisphere轮询次数

·         检查MetaLUN配置是否有磁头竞争(linked contention)问题。参考知识库文档emc188729: "Fixing 'linked contention' performance issues"

·         根据知识库文档emc226845: "Best practices for creating metaLUNs on VNX or CLARiiON arrays"，迁移混合的MetaLUN (多个条带化的MetaLUN串联在一起哦)至单一的MetaLUN

·         确保主机、交换机和CLARiiON的网卡速率都设在了相同的速度。SP管理网口默认是自适应的，交换机最好也设为自适应

·         增加运行有Navisphere Manager的主机的Java运行内存至128MB或更多。参考知识库文档emc192269: "Slow response from Navisphere Manager GUI or Off-array Manager"

·         使用最新的存储软件版本

·         在Navisphere Setup页面中增加Navisphere轮询间隔(polling interval)至最大的300秒

·         一旦完成SP使用率的测量和性能数据的抓取后就禁用统计日志(statistics logging)

·         确保所有的navicli/naviseccli脚本都使用了-np (No Polling功能)。尽量避免使用长队列的Navisphere CLI命令脚本

·         取消注册所有不再使用的主机。如果仍有未使用的主机initiator登入，需要更改FC交换机Zoning设定。

·         如果Connectivity Status中出现了不是为了MirrorView或SAN Copy而加入的CLARiiON initiator，应该在FC交换机上移除它们

     

如果实施了上述操作后仍然不能将平均SP使用率降到一个可接受的水平(50%左右)，就可以开始考虑升级存储设备了。

无

参考下列EMC知识库文章：

emc207795       How to reduce CLARiiON SP utilization and Navisphere/Unisphere response times

emc186107       How to improve performance on a VNX or CLARiiON storage system that is forced flushing

emc226845       Best practices for creating metaLUNs on VNX or CLARiiON arrays

emc206697       CLARiiON: Large number of concurrent LUN creations when using FLARE Release 28.003 to 28.506 on CX4 Series may impact performance

emc188729       Fixing 'linked contention' performance issues

emc213405       Should I be concerned if SP CPU utilization is running at over 50%?

emc192269       Slow response from Navisphere Manager GUI or Off-array Manager

CLARiiON系列