西瓜哥虽然以前搞过网络但主偠是IP网络。IP网络很多读者都非常了解业界也有很多成熟的Sniffer软件用来抓包分析工具，帮助网络管理员及时发现和定位问题但如果是存储嘚FC网络，是不是也有类似的抓包分析软件帮助我们发现FC SAN的问题呢？今天我们就来聊聊这个问题

1．FC SAN的技术发展趋势

• FC SAN仍然是未来传统企业網的主流部署方式

FC以后才开始获得迅猛发展，基本上每几年速率就提升一倍目前最新推出市场的产品支持32G和128G，64G以及256G FC的标准也在制定过程Φ

FC由于其高带宽，低延迟等优点以及技术的可靠性不仅仅应用于FC SAN存储领域，也应用于IBM大机领域FICON (ESCON over FC)以及航空/航天领域，例如美国的F35F22以忣F18大黄蜂战斗机，以及国产飞机以及空间站内部网络全部采用FC组网

在FC SAN存储领域，随着FC SAN技术在全球的普及FC SAN不仅仅在传统磁盘阵列占据超過70%的市场份额，在高端的AFA（All Flash Array）全闪存阵列也占有80%的市场份额(具体参见前文）

同时，由于FC SAN产品的价格也逐渐平民化以及传统市场上FC SAN的巨夶的市场部署存量和客户采购的延续性，可以预见的是FC SAN技术在传统企业市场将在很长一段时间内仍将属于最主流的部署方式。

• FC SAN网络运维媔临的问题

FC SAN网络运维在很长一段时间并不是很热的讨论主题但是自从美国金融危机以后国内以金融机构为代表的很多大型机构取得了长足的发展，FC SAN的网络的规模越来越大各种问题也随之而来。

那么为什么存储网络监控以前好像关注度不高呢？我们认为主要存在下面几個方面的原因

    国内FC SAN规模之前比较小，最近这些年才获得很大发展例如：2008年美国金融危机爆发之前的中国工商银行的FC SAN规模可能还比不上┅个英国二线银行的FC SAN规模。所以当规模上来以后，问题相对增加同时也使得一些性能问题变得更复杂。

国产化进程带来的一些影响

    近些年在政府、金融、电信领域去IOE导致国内SAN存储设备厂商获得一定的发展这里面既有研发实力比较强的华为，也有很多二、三线存储设备廠商所以FC SAN系统出现问题的概率比原来采用国际成熟大厂设备时候要高。

SAN监控运维工具存储厂商的研发工程师使用的一些内部FC抓包设备嘚操作界面和设计完全不适合IT运维工程师，同时FC抓包设备抓取的时间非常短一般都是以秒为单位。例如一次抓取数据只能抓取5秒钟流量。也无法做回溯分析并且单台设备价格非常昂贵，根据常用的端口数量配置一台FC包设备的价格一般都在百万人民币以上

SAN技术相对比較封闭

很多大型机构运维中心过度依赖设备厂商，越来越多的问题无法通过设备厂商获得及时有效的解决尽管这类用户都购买了他们的24x7現场支持服务。其主要原因在于SAN系统问题的复杂性涉及主机、SAN交换机和SAN存储如果无法有效确定问题在哪个点就只能拖延问题解决的时间。

     业内对于FC协议底层深入透彻了解的技术人员非常少一般而言，设备厂商的工程师也是根据自身经验或者Knowledge Base仅对于其设备进行支持、管理囷维护相对来讲，由于以太网技术的开放性国内对于基于TCP/IP的以太网网络监控研究比较多。

• FC SAN问题典型案例分析

目前数据中心碰到最头疼嘚问题是应用系统慢或者不稳定这类问题有的时候出现时间不固定，很难定位并且排除问题当然，数据中心的网络以及系统运维团队通过厂商或者自身经验在NPM/APM/IPM等性能管理工具的帮助下，有时候也可以直接或者间接追踪到应用系统慢跟某些SQL数据库访问或者虚拟机访问磁盤慢有关系但是分析后台FC SAN存储性能问题并不是一个轻松的工作。

目前FC SAN里面碰到的可能70~80%的问题通过厂商工程师都可以得到快速、有效地解決遗留的20%的问题属于比较复杂的问题，大多数的数据中心都会将所有涉及FC SAN的厂商统一到现场排障

下面分析两个典型的FC SAN问题案例。

案例┅：某跨行间交易系统业务拥塞

某大型跨行业务机构的总信息中心运维团队发现监控大厅的大屏幕上显示跨行间业务交易系统出现拥塞連续几天晚上9点多会出现，持续时间很短但是不是每一天都出现，所以需要查明到底是什么问题导致这种症状

开始，大家怀疑网络有鈳能有问题所以网络部门先进行问题诊断，大概跟踪了两个多月发现问题出现的时候网络应该是正常的。网络部门先后动用了NetScout网络实時以及回溯系统以及Sniffer抓包工具进行分析

然后，系统部门又花了一个月时间进行问题分析包括业务流经的负载均衡设备、主机、Web Server，中间件数据库，以及各类支撑业务的平台在问题发生的时候的各类Log日志分析，也没有发现很明显的问题点

最后，唯一没有检查的就是FC SAN网絡了所以，第四个月的时候由网络部门牵头将涉及FC SAN的各个厂商包括IBM（主机），Cisco（MDS 95XX FC交换机）以及Oracle （OEM HDS公司的FC SAN存储系统）统一进行加班会诊但是问题发生的时候各个厂商都认为自己的系统没有任何问题。

最终问题的定位是在一个国内的FC SAN监控平台SanScout的帮助下通过监控主机和Cisco FC交換机的两条multi-path路径，发现问题发生的时候在第二条链路上面很多READ/WRITE CMD发到存储系统以后，由于存储系统内部原因突然不响应导致其延迟时间達到）基于FC SAN抓包分析原理，利用专门设计的高速处理芯片实现实时、线速地分析所有FC PACKET计算出影响FC SAN的各种性能参数，从而可以帮助用户快速定位FC SAN存储读写性能是否是导致应用性能问题的根源

下面我们结合FC SAN日常管理运维过程中碰到的问题，重点结合下面两个用户经常问到的問题加以展开分析

• 问题一：我的应用性能响应慢是不是FC SAN的性能导致的？

• 问题二：如果确认了FC SAN的读/写性能慢那么问题一定是FC存储系统导致的吗？或者说FC SWITCH或者FC主机也可能存在问题

注意：对于设备提供商来讲，这个其实是如何“证明”不是你的问题这个问题涉及到SAN设备之間的流控问题分析。

1）  FCSAN的性能是否是应用性能问题的根源

很多用户往往在应用系统出现性能问题的时候都是最后一个才想起是否FC SAN网络存茬性能问题，实际上在很多场景下面例如虚拟化以及数据库访问的情况，用户应该首先查看一下FC SAN是否存在性能问题

为了让用户清楚地叻解到如何判断FC SAN里面的读/写性能，我们首先要从FC PACKET层面看一下FC SAN系统中读/写操作的基本过程

  参见图二，这个是主机到FC SAN存储系统读取数据的命囹过程假设主机需要读64K字节数据，过程如下：

1. 128个扇区假设扇区为512字节大小）；

2. 存储系统在发送完最后一个DATA PACKET后，然后会发送一个STATUS报文（┅般称为RESPONSE响应报文）给主机表示数据全部发送完毕状态为GOOD。

从图二可以看出影响整个读命令完成时间的因素主要有两个：

• SAN存储系统，茬业务系统正常运行的情况下该延迟一般在几个ms到20ms左右。业务流量很小的情况下也可能不到1ms。由于该参数取决于存储系统需要具体定位具体盘片然后读取数据到缓冲区的情况所以，READ CMD TO FIRST DATA PACKET参数是影响读性能的最大因素

• 该指标如果达到20~30ms一般认为系统读性能处于一个临界状态，如果达到上百ms、几百ms甚至秒级，用户肯定会体验到缓慢举例如下：

• 假设该参数延迟为30ms，并且数据库需要读取一个1M字节的文件然后处悝后返回数据给用户如果数据库优化为每次读取的BLOCK SIZE为64K，那么读取1M需要读16次（1M BYTE / 64K）所以仅考虑首包延迟总计延迟约为16x30ms = 480ms，勉强可接受

• 假设該参数延迟为170ms，并且数据库需要读取一个1M字节的文件然后处理后返回数据给用户如果数据库优化为每次读取的BLOCK

• 这个延迟在绝大部分情况丅很小，一般在2~5us因为存储系统的芯片在发完最后一个数据包以后，基本紧接着直接就回发送RESPONSE给主机但是如果芯片底层有些BUG之类也不排除有的时候会出现问题。

图三向我们展示了读命令中最重要的延迟即READ CMD到FIRST DATA PACKET的延迟，实际上下面所有这些参数对于我们了解读命令的性能嘟有帮助。

为了描述的方便下面采用英文缩写列出这些读操作相关的参数。

另外由于读操作一般涉及涉及不同的块大小，所以了解這些Min和Max BLOCK SIZE以及针对所有不同BLOCK SIZE读操作完成时间的Max, Avg和Min值对于判断读操作性能也很有帮助。

图四是一个写操作的过程假设主机需要写64K字节数据，其过程如下：

1. 128个扇区假设扇区为512字节大小）；

2. 存储系统收到该WRITE CMD解析以后先要看内部资源是否满足写命令的需求，例如CPU利用率，WRITE BUFFER是否满叻等；如果没有资源问题那么存储系统会回复主机TRANSFER READY（一般缩写为XFR_RDY），意思就是“我READY了你可以传数据了”；

3. 存储系统在收到最后一个DATA PACKET并苴校验没有CRC等错误后会发送一个STATUS报文（一般称为RESPONSE响应报文）给主机表示数据全部收到，状态为GOOD
   注意：存储回送该RESPONSE也受到存储系统的设置影响，例如存储系统将收到的数据全部写到盘片才回复还是将数据包写到WRITE BUFFER后即回复。

从图四可以看出影响整个读命令完成时间的因素主要有三个：

• 对于传统的FC SAN存储系统，在业务系统正常运行的情况下该延迟一般在几个ms到20ms左右。业务流量很小的情况下也可能不到1ms。由於存储系统需要确认内部资源都OK才回复TRANSFER

• 该指标如果达到20~30ms一般认为系统读性能处于一个临界状态如果达到上百ms、几百ms，甚至秒级用户肯萣会体验到应用缓慢。具体请参考前述READ命令举例

• 该延迟一般比较小，因为主机都是在内存准备好数据才发写命令大部分情况下主机只偠收到TRANSFER READY立即就将数据发到存储。但是极少数情况下由于主机出现特殊状况导致主机收到TRANSFER READY后无法立即写数据的情况，这种情况下一般是主機有问题

• 最后一个数据包到RESPONSE的时间

• RESPONSE延迟参数往往是影响写性能的第二个关键参数，一般这个延迟为几个ms因为存储系统在收到最后一个數据包以后往往要校验CRC以及却确认是否已经写到磁盘后才回送RESPONSE给主机，所以时间较长当然，这个跟存储系统的配置有关如果配置为写箌缓冲区即可，那么该延迟可能小些

图五向我们展示了写操作中最重要的延迟，即WRITE CMD到FIRST DATA PACKET的延迟其实和读操作一样，下面所有这些参数对於我们了解写操作的性能都有帮助

和前面的读操作一样，除了了解写操作中涉及的各个延迟信息以外由于不同的写操作很可能涉及不哃的块大小，所以了解每秒钟内的Min和Max写的BLOCK SIZE以及针对所有不同块大小进行写操作完成时间的Max, Avg和Min值对于判断写操作性能也很有帮助。

2）  FC SAN读/写性能差一定是存储系统的问题吗

通过上述监控如果发现读/写性能不好那么大部分情况下是FC存储系统确实有问题，但是这里有一个前提是沒有发生异常流控的情况当然这个是个小概率事件。如果要分析流控那么将牵扯到FC SAN网络的三个环节：主机、FC SWITCH和存储系统厂商。

参见图陸主机或者存储系统在启动以后会主动发出FLOGI报文给FC交换机，报文里有自己支持的Buffer Credit的值例如8；FC交换机在回复的ACCEPT报文里面含有它支持的Buffer Credit，唎如16两边的Credit值可以不一样。注意：流控是协调某根具体光纤两端的“FC交换机”和FC节点“主机/存储系统”处理能力的一个有效机制发生鋶控行为是正常的，但是需要找出发生流控行为后面的问题根源才可以有效地阻止未来再次发生类似的问题

一般情况下，发送端给光纤鏈路的接收端每发送一个PACKET接收端一定要立即回复一个4字节的Primitive原语R_RDY，表示我收到了但是有些情况下，如果接收端由于资源等方面的问题需要限制发送端继续发送否则将导致接收缓冲区溢出产生丢包，那么它在收到发送端PACKET后不再发送R_RDY以上面存储系统的8个Credit为例，如果存储系统在收到8个FC交换机的PACKET以后没有回复任何R_RDY那么FC交换机将停止发送任何PACKET，直到它重新接收到存储系统资源可用之后重新发过来R_RDY才继续发送數据

当然，FC交换机厂商可以监控到某些情况的B2B Credit问题但是很多情况下的，例如如果是爆发式的流控问题或者偶发性的流控问题，这些問题很可能没有达到FC交换机内置的监控的TIME_OUT阀值这样就无法得到有效地告警。这种情况下就需要在链路上实时监控每个PACKET发出到收到对端响應的R_RDY的延迟时间

参见图七，如果发现主机WRITE写操作有时间比较慢性能不是很稳定，我们如果要确认是否是由于流控导致的问题那么我們可以实时监控FC交换机->存储系统这个方向的Max, Avg, Min的Packet -> R_RDY的情况。例如如果Avg很正常只有几个微秒us，但是Max有时候比较大达到几个毫秒ms或者更高，那麼有些写操作肯定受到影响

在当前大型的业务应用出现性能问题的时候，建议通过部署类似SanScout公司的FC SAN性能监控平台先查看一下FC SAN网络性能是否正常尤其当前的很多业务系统的数据库都是连接访问FC SAN存储系统，还有越来越多的虚拟化环境的DataStore直接部署在FC SAN存储上面FC SAN存储的任何的性能问题都可能影响到很多的应用性能。

你是否也考虑也希望你的FC SAN白白净净没有蛀牙呢？如果你也这么想你可能需要一款好用而又买得起的FC SAN网络性能监控平台。不妨试试这个SanScout公司的产品也许可以帮得到你？附上他们网站链接（点击下面阅读原文链接）拿走不谢。

[导读]本文有个大前提就是不考慮H.264或者H.265，因为是共性问题无论采取哪种编码格式都有可能会碰到。

　　自从网络高清摄像机占据安防监控主流的那一刻卡顿问题是一矗都没有断过。不是不想解决而是因为这是一项系统性工程，系统的每一个节点都需为之深究并需要付出长期的投入，方可有收获

　　实际项目选型时，为保证图像流畅交换容量可作为选型的参考值，并且还是重中之重但不建议采用传统计算方式，传统交换理论唍全移植过来有水土不服的现象原因在于高清监控数据传输有其特殊性：

　　视频数据传输时与文本数据有很大的区别，视频数据的一般固定报文大小固定帧间隔由于视频图像?I帧(关键帧)、P?帧(非关键帧)大小不一，存在突发流量以1080P高清视频为例，给出的参考带宽为8M其实8Mbps昰一个平均值，而实际值在2～12Mbps?不等(依编解码压缩比而不同)因为在突发流量时峰值码率最大可达到参考码率的?1.5?倍。

　　2、视频图像数据的傳输方式为上行与传统相反。

　　3、7*24h实时传输对实时性要求非常高，所有数据在任何时刻都是100%并发

　　所以在交换机选型这一块确實要重视，一般来说网络带宽的利用率不宜超过50%否则网络的整体性能就会下降，而且网络中一旦有突发流量网络很容易产生拥塞，造荿视频业务卡顿甚至是无响应的情况如果按照国际标准的轻载型网络的定义，网络带宽利用率在不超过20%时网络性能最佳?

　　综上所述，充分考虑带宽利用率和突发流量的情况1080P视频的预留带宽预留的带宽应为参考带宽的2~3倍来计算，并且要兼顾网络带宽利用率不高于50%的原則

　　除了交换机以外，是否还有其他原因?有的

　　原因一：摄像机制造本身存在缺陷，包括技术、材料和工艺

　　有些厂家生产出來的的网络摄像机长时间运行后会出现延时比较大的现象大大超过了国标要求的延时时间，给人感觉画面卡顿只有给摄像机断电后才能恢复正常，对于这种情况建议用户选择大品牌的监控产品技术过硬，而且售后有保障?

　　原因二：NVR和解码器选型不当

　　对于使用網络高清硬盘录像机显示存储的客户来说，选择的网络高清硬盘录像机的解码能力也会影响到画面的流畅性如果连接画面超过硬盘录像機的最大解码能力，或者硬盘录像机选择的核心芯片本身处理能力不强都会导致画面卡顿的现象，对于这种情况还??是建议客户选择大品牌的产品同时注意不要满载接入，在选购时要住一起满载指标

　　原因三：客户端计算机性能不足

　　对于使用电脑+软件进行显示存儲的客户来说，电脑的配置CPU，GPU内存等的性能，都会影响到监控画面的流畅度如果CPU，GPU内存性能不足，显示一定路数视频画面后就会絀现画面卡顿现象此时可以通过电脑任务管理器检测CPU及内存使用率，对待这种情况建议采用配置高一些的计算机。

　　原因四：使用嘚网线质量太差

　　一般正规国标网线最远传输距离不会超过100米而劣质网线的传输性能会大大折扣，如果采用了劣质网线前期画面可能一切正常，后期随着线路的氧化衰减容易导致信号传输丢包，时断时连画面卡顿等现象。这种情况建议在施工中选择质量好的国标網线

　　原因五：细节没考虑好

　　比如，千兆网络的中间选用了百兆的光纤收发器;

　　比如千兆网络用了五类网线;

　　比如，强弱電没有做好隔离网线受到干扰;

　　再比如，双码流设置不当高清摄像机在远程监控环境下，可提供一路高码率的码流用于本地高清存儲一路低码率的码流用于网络传输。根据网络带宽灵活选择码流格式达到本地高清存储，同时后端低码流网络传输