专家问答“VNX上软件设置或硬件问题可能导致性能下降的分析和处理”精华整理

zhouzengchao
4 Germanium

专家问答“VNX上软件设置或硬件问题可能导致性能下降的分析和处理”精华整理

专家问答“VNX上软件设置或硬件问题可能导致性能下降的分析和处理”精华整理

转载请在文首保留原文出处:EMC中文支持论坛https://community.emc.com/go/chinese


介绍


在第九期的专家问答中,来自EMC售后技术支持部门的两位工程师为我们提供了精彩的问答讲解,我们在此对该期专家问题的问题和解答进行了精选,方便大家参考。


更多信息

问题1VNX上哪些设置会影响到LUN的切换?是否有推荐的设定,可以减小LUN切换所带来的负面影响?在LUN发生切换时,从客户端应用的表现来看一般会有什么症状?怎么有效的查看系统里是否曾发生过LUN切换?


回答:

1) VNX上每个LUN都有"AUTO ASSIGN""AUTO TRESPASS"两个参数, LUN分配给主机后, 该两参数就应该被"DISABLE",因为一般主机都有路径管理软件, 主机的路径管理软件会通知VNXSP控制器何时进行切换, 例如主机的路径管理软件发现该LUN突然无法访问。

2). 针对不同的主机操作系统和路径管理软件, VNX上注册的每台主机HBA卡都有4个参数可以设置,"FAILOVER MODE","INITIATOR TYPE","ARRAYCOMMPATH(LUNZ)""UNIT SERIAL NUMBER",  主机操作系统和路径管理软件必须与以上4个参数,尤其是"FAILOVER MODE"相匹配, 如果不匹配就可能导致LUN频繁切换。具体配置可参见emc99467.

3)在LUN发生trespass时,如果不是很频繁, 从客户端应用的表现和往常差别不会太大。但如果很频繁,例如几分钟内几十上百千次, 对业务的影响就会非常明显。一般SPEVENT LOG里都可以看到切换事件。

LUN发生trespass主要由以下几个原因:

1). 软件问题:

a. HBA卡的FAILOVER MODEVNX上设置不正确(即与主机的OS类型和多路管理软件不匹配

b. 主机上一条路径的LUN被不只一个多路管理软件控制

c. 未设置"ALUA"模式

2). 硬件问题:

a. HBA卡处于时好时坏的不稳定状态

b. 光纤环路上任一部件 (例如沮丧表情WITCH上的SFP)处于时好时坏的不稳定状态

c. 两种不同类型的HBA配置在同一主机上

问题2 能详细介绍下ALUA模式以及它的一些设置可能会带来的影响吗?ALUA默认或者推荐情况下,应该都是开启的吧?有需要禁用它的特殊情况吗?

回答:ALUA是为了模拟Active/Active架构,减少LUN切换而设计的一种故障转移模式。它通过在软件层面引入Upper/Lower Redirector,可以在不切换LUN的情况下,通过CMI接口让I/O通过对端SP的前后端口访问到最终数据。例如,当LUN所有者SP的前端端口故障时,路径管理软件会将I/O重定向到对端SP的前端端口,然后对端SP通过Upper RedirectorI/O通过CMI发送给LUN所有者由其进行处理,从而避免了LUN切换。同样,但LUN所有者SP的后端连接故障时,所有者SP会将I/O通过Lower RedirectorCMI发送给对端SP,对端SP通过其后端端口拿到数据后返回给LUN所有者SP进行处理。

     ALUA虽然避免了LUN切换可能导致的I/O错误,但同时由于I/O路径变得冗长,对性能有一定的影响。如果系统能在短时间回复前端或后端连接,那么I/O将使用原本的最优路径。但如果路径长时间故障,系统会在接收到一定数量的I/O之后,将LUN切换到对端SP。因为在系统看来,原本的路径可能无法在短时间内恢复,切换到对端SP重新使用最优路径进行数据访问。


     ALUA是否开启取决于主机和存储的配置。在VNX上,必须将主机注册信息的Failover Mode设置为4才算启用ALUA

     ALUA是推荐的配置,要说特殊情况需要禁用的话,那就是主机和/或存储不支持ALUA,此时就需要禁用。不过现在的OS和存储几乎都是支持ALUA的。


问题3
可能对NAS访问性能产生影响的一些VNX File端的设置有哪些?


回答:这里需要先讲一下文件系统的结构,NAS的文件系统是建立在后端(SAN)给NASLUN上面的。那么具体的结构、布局是怎样的呢?在这之间,有一个volume的概念。

1. 首先,NAS会将后端的LUN识别成disk volume


2. disk volume之上,我们可以建立一些其他类型的volume。例如:stripe volumeslice volume,以及meta volume。介绍如下:


     a. stripe volume:一般出于对性能的考虑,我们会将多个disk volume放在一起组成一个stripe volume。这样可以将volume上的I/O同时分散到后端的多个LUN上。

     b. slice volume:考虑到对存储容量的有效利用,我们一般会按照需求,将stripe volumedisk volume的一部分切片,并创建成slice volume。这样一个较大的stripe volume可以被多个较小的文件系统使用,而不是被一个文件系统独占。

     c. meta volume:一个逻辑上的概念,它可以由任何其他volume组成。通常

文件系统只能建立在meta volume上。这样做的好处是方便扩展。扩展一个文件系统的时候,系统实质上是建立一个新的volume,并且将它加入到文件系统所在的meta volume的成员中。

     一般我们通过Automatic Volume ManagementAVM)建立文件系统的时候,系统都是通过a->b->c的过程依次创建这些volume,最后再将文件系统建立在meta volume之上。这样做的好处非常明显,可以保证文件系统的性能,有效利用空间,并且易于扩展。如果需要手动建立volume并建立文件系统,而不是通过AVM的时候,也应该注意这些步骤。

问题4在上一个新系统前,有什么关于文件系统的布局和volume划分方面的指导意见吗?从而在一定程度上避免或帮助减缓以后由于不合理的文件系统布局和volume的划分所带来的性能上的负面影响?


回答:首先,我们创建文件系统一般有2种方式:


1. 手动创建各级volume,最后选择从meta volume创建文件系统。
2.
File storage pool中创建。NAS会使用称为AVM的算法自动完成挑选disk volume,并依次创建各级volume的过程。

     这里File storage pool是一个什么概念呢?NAS会根据disk volume(也就是后端LUN)的RAID类型、磁盘类型,将同类型disk volume归类到系统定义的File storage pool中。例如,所有来自RAID 5SAS盘的LUN,都将被归到叫做clarsas_archivestorage pool中。在创建文件系统的时候,通过选择storage pool,我们可以很直观的选择文件系统被存放在什么类型的LUN上。那么,AVM是如何在storage pool中选择disk volume创建文件系统的呢?


对于大多数系统定义的storage poolAVM根据以下标准创建最优化的stripe volume

1. 挑选的disk volume大小必须相同
2. disk volume
必须来自不同的RAID group
3. disk volume
必须来自同一个后端SAN存储
4.
一些优先选择条件:

     a. 优先从使用率最低的RAID group选取
     b.
选取的disk volume平均分布在2SP
     c.
选取的disk volume平均分布在不同的bus

     根据以上条件,AVM将优先选取4disk volume创建stripe volume。如果没有满足条件的4disk volume,则依次减少一个再次进行选取。

     创建好了stripe volume以后,根据storage pool属性里的default_slice_flag,以及创建文件系统时候指定的“slice={y|n}”参数(可选),系统将会决定是否对stripe volumeslice

     1. 如果pooldefault_slice_flag=y或者指定了slice=y,系统将会根据需要建立的文件系统大小,将stripe volume切片,创建一样大小的slice volume。这样,stripe volume剩余的空间将来还可以创建其他slice,用来建立其他文件系统,或者用来扩展文件系统。

     2. 如果pooldefault_slice_flag=n或者指定了slice=n,系统不会创建slice volume,而是将整个stripe volume的空间都留给新建的文件系统。这样做的好处是有助于提高性能。因为被该文件系统所使用的LUN上不会再有其他的工作负载。

     最后,在之前创建的stripe volume或者slice volume上创建meta volume,并最终在其之上建立文件系统。

     总结:AVM的算法中我们可以发现以下几点影响访问性能的因素:

1. 是否合理的创建了stripe volume - 理论上说,stripe volume包含的LUN越多=越好的性能(当然,前提是这些LUN都来自不同的RAID group)。这样做可以把文件系统的I/O分散到各个RAID group的磁盘上。


我们在后端创建RAID groupLUN的时候,也可以注意以下几方面,以便于AVM找到合适的LUN


     a. 创建多个相同类型的RAID group,分布在不同的Bus上。
     b.
在每个RAID group中创建相同大小的LUN。一般建议可以每个RAID group创建2LUN,一个给SPA,另一个给SPB

2. 是否使用slice - 从应用的角度出发,判断需要更有效的空间利用率还是更好的性能,以决定创建文件系统的时候设置对应的“slice={y|n}”参数。


关于AVM以及手动创建storage poolvolume、文件系统的更多信息,可以参考support.emc.com上的以下2PDF文档:

- Managing Volumes and File Systems for VNX Manually

- Managing Volumes and File Systems with VNX Automatic Volume Management

问题5. CAVA这块主要提到了对写性能影响,是不是说如果部署了CAVA,写性能(相对于读性能)是需要重点考虑的?能再详细点阐述下CAVA在扫描CIFS共享文件时在读性能和写性能上的一些区别吗,或者说为什么写性能(相对于读性能)会对于CAVA所带来的影响更加敏感?


回答:关于CAVA,一般在两种情况下,会对CIFS共享文件进行病毒扫描:

1. 在写入时扫描 - CAVA 会在修改和关闭文件后启动扫描。如果打开了文件但未对其进行修改,则CAVA 不会在文件关闭时执行扫描。

2. 在第一次读取时扫描 - CAVA 根据文件的访问时间来确定是否扫描该文件。AV 引擎会将此访问时间与EMC CAVA 服务中存储的参考时间进行对比。如果文件的访问时间早于参考时间,则在CIFS 客户端打开此文件之前,AV 引擎会在读取此文件时对其进行扫描。

     在AV 引擎上检测到病毒定义文件更新时,CAVA 将更新“在第一次读取时扫描”访问时间。由此可见,“在第一次读取时扫描”在每次更新病毒定义后,对于每个文件仅会发生一次。因此,“在写入时扫描”发生的频率一般要高于“在第一次读取时扫描”。当病毒扫描发生时,文件的访问(读取或写入)会被挂起,直到扫描完成。所以说CAVA对于CIFS访问的性能(尤其是写性能)是有一定影响的。如果用户环境中的访问数量较大,配置的AV服务器来不及处理扫描请求,用户可能就会比较明显的感觉到访问性能下降的问题。

     当正在进行中的病毒扫描请求数量大于在viruschecker.conf配置文件中所定义的lowWaterMarkhighWaterMark数值时,CAVA将向VNX发送日志事件。默认lowWaterMark=50highWaterMark=200。如果我们在VNX日志中频繁发现这样的事件,说明AV服务器不能及时响应病毒扫描请求。

     您可使用CAVA Calculator CAVA 大小调整工具来确定系统需要的AV 服务器数量。CAVA Calculator 可为您提供安装前的帮助,并且您可在安装后使用此工具运行假定情形分析。CAVA 大小调整工具会从正在运行的环境中收集信息,为您提供有关所需CAVA 服务器数量的建议。如果需要考虑容错问题,您至少应在网络上配置两个AV 服务器。如果其中一个AV 服务器离线或VNX 无法访问AV 服务器,则使用两个AV 服务器可确保维持文件扫描功能。如果网络上有多个AV 服务器,VNX 将以循环调度方式分发扫描任务,以此平衡多个AV 服务器之间的负载。例如,如果一个AV 服务器离线,VNX 将在其他可用的AV 服务器之间分布扫描负载。

更多信息 ,可以参考“使用VNX Event EnablerPDF文档。

     另外,这里说一下关于CAVA的一个比较重要的参数。在viruschecker.conf配置文件中,我们可以定义“shutdown=”参数,指定在无任何AV服务器可用时采取的关机操作。

选项中包含下列参数:


shutdown=cifs

在无AV 服务器可用时停止CIFS。(所有Windows客户端都将无法访问任何VNX 共享。)

如果严格的数据安全性在您的环境中很重要,您应启用此选项,以在所有AV 服务器均不可用时阻止客户端对文件的访问。如果此选项处于未启用状态,同时所有AV服务器均不可用,客户端将可在无任何病毒检查操作的情况下修改文件。

注意: 如果您配置的AV 服务器数量小于2,则应禁用shutdown=CIFS

shutdown=no

在无AV 服务器可用时继续重新尝试列出AV 服务器。此时存在两个水位线(高和低)。在达到每个水位线时,将会发送事件日志。请使用事件日志来在Data Mover 上执行正确的纠正措施,以确保病毒检查功能运行正常。

shutdown=viruschecking

在无AV 服务器可用时停止病毒检查。(Windows 客户端可在无病毒检查的情况下访问VNX 共享。)

此参数的默认值为shutdown=no

用户应当根据实际需求考虑,合理设置该参数。

如果需要严格控制数据安全性,可以考虑设置shutdown=cifs,但这样做可能会导致CIFS共享在无AV服务器可用时出现无法访问的情况。

若需要保证数据的可用性,可以设置shutdown=viruschecking。这样即使AV服务器不可用时,也能保证CIFS共享的访问,但是其上的数据将不会进行病毒检查。

问题5. 一台5700,挂在NFS上面的程序进程总是无故挂起,存储后台看又没发现特殊的,其中某个网络端口偶尔有丢包。有什么更好的诊断思路么?


回答:关于诊断思路,个人认为首先可以查看下NFS客户端的日志,以及VNX的日志,确认有没有NFS相关的报错信息。如果怀疑是性能问题,可以运行server_stats server_x -monitor nfs-std 或者 nfsOps-std 查看VNX Data Mover层面上NFS共享的访问速率以及响应时间。如果怀疑是网络问题,可以运行server_tcpdumpNFS客户端连接的Data Mover的网络端口上抓包,进一步分析网络上是否有丢包或者其它问题。一般认为TCP重传率不应超过0.1%,否则可能导致共享访问性能下降问题。TCP重传率高,一般是由用户网络问题导致的,而非NAS端的设置问题,例如网络佣塞。从NAS这边来讲,我们可以在Data Mover上启用tcp.fastRTO参数,以加快TCP重传过程(将重传超时时间从1.5秒减少到0.5秒),从而改善性能。然而,需要根本的解决TCP重传率高的问题,还是要从用户网络方面排查。


问题6. 在对VNX系统做性能上的评估或分析测试时(比如NAS或是block方面的),一般会用到哪些工具或方法?有没有你们自己常用的工具或是方法可以推荐一下的?


回答:NAS方面,在图形界面里,我们可以使用Celerra Monitor来看VNX File在过去3个月的性能数据。在命令行里,我们可以运行server_stats命令实时查看Data Mover的各项性能参数。例如CIFSNFS的访问速率,以及各项操作的响应时间。

如果怀疑用户网络问题导致性能下降,我们可以运行server_tcpdump命令在Data Mover端口上抓包进行分析。

另外,还有一些其他命令,例如server_netstat server_2 -i -p tcp可以用来查看Data Movertcp重传率;“.server_config server_2 "printstatsscsi"”可以看Data Mover到后端存储的光纤上的繁忙程度以及I/O等待数量,从而判断是否后端存储是性能瓶颈。


参考

原帖:https://community.emc.com/thread/171846


应用于

VNX Unified系统

版本历史
修订号
1 / 1
上次更新时间:
‎05-05-2013 11:41 PM
更新依据: