未解决
此帖子已超过 5 年
2 Intern
•
4K 消息
0
1725
如何降低CLARiiON SP使用率和Navisphere/Unisphere响应时间
如何降低CLARiiON SP使用率和Navisphere/Unisphere响应时间
介绍
本文列举了造成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系列