Find Communities by: Category | Product

Ensure all servers attached to your storage array have storage path management software, such as EMC PowerPath, that is correctly installed and configured for path failover. EMC recommends Round Robin path selection policy for XtremIO

 

相信大家在EMC 最佳实践文档中见过以上内容,简而言之,EMC推荐使用“Round Robin”作为NMP Policy以确保XtremIO升级的正常进行。

 

首先,我们来看看NMP到底是个啥玩意儿?

NMP =  Native Multipathing Plug-IN, 中文名为“本机多路径插件”。

其一共有三种模式,分别为 MRU,Fixed, Round Robin。

MRU (Most Recently Used): 最近使用策略,当系统启动后,第一个被发现可以工作的路径,如果不行,就一直试到好用的一条路径为止。当原路径恢复后也不会回切。适用于存储类型为Active/Passive主备模式。

Fixed: 固定策略,也是开机后的第一条可用路径,如果失效的链路恢复,会采取回切。适用于存储类型为Active/Active的模式。

Round Robin(RR):循环策略,以轮询的方式选择所有可用路径,这是最佳实践推荐的模式,但并不是所有存储都支持这种策略。

 

介绍完了NMP,我们就赶紧步入正题,一步一步来教你设置NMP。

 

第一步:选择“配置”

 

第二步:选择“存储器”

11.jpg

第三步:右键选择“属性”

22.jpg

第四步:选择“管理路径”

33.jpg

 

第五步:选择“循环”

 

以上,Round Robin已经设置完成,是不是很简单?那还等什么,赶快去教男神设置NMP吧。

 

今后还会定期推出老司机系列,所有内容都将会更新在首页“实战教程”中,敬请期待哦。

 

作者信息:

郑永亮(Derek Zhang)

亚太地区上海远程变更管理团队(Remote Proactive Team)升级工程师,负责XtremIO相关产品的升级工作。

原文出处: XtremIO社区  http://mp.weixin.qq.com/s?__biz=MzIwMTc5NzQzMw==&mid=2247483684&idx=1&sn=a957318e4fe75ab9cd2296cba18ba7f2&scene=1&srcid=0520b5JdiPv29BVZzp3c1fzP#rd

 

 

远程变更管理团队的日常工作,即是通过远程连接,如Webex或是EMC安全远程支持(ESRS)为客户进行服务,提供技术支持。

 

这次有幸能和现场工程师一起深入客户机房,体验一把onsite,现场经历远程协助的整个过程,现在想想都还有点小激动呢。

 

远程协助往往掌握着更多的资源,能更及时的对客户需求进行协同分析,调阅相关文档,从而制定解决方案。远程协助和现场协助都是本着EMC以客户为先,以服务至上的原则,确保客户能得到始终如一的优质服务。然而,不可否认的是在现场,往往要承受更多的压力。

 

此行前往现场,主要任务是对客户的XtremIO进行一次版本升级,客户的应用环境采用的是VNX+Vplex+XtremIO的解决方案。

 

这一次我的任务是帮助客户对远程协助进行更好的了解,对客户的疑问进行解答,整个升级工作仍将有资深工程师在远程进行通过Webex操控执行。在和客户的交流之中,客户对远程协助的好处也是深有感慨,并决定在近日上线ESRS的服务,这样就能与EMC的呼叫中心形成对接,全方位的7*24小时对设备进行监控,如发生报警,远程协助便能在第一时间对报警进行响应,排查故障。

 

每次升级之前,我们都会依循检查清单对客户环境进行验证,以期确保升级顺利进行,且对业务保持无中断。在预检结束之后,升级便在预约时间准时开始,整个升级过程都将由远程变更管理团队进行监控,并在每一个预设的检查点做出对当前任务的报告以及对下一步计划任务的概述,而客户将得到彻底解放。我不会告诉你在做升级的时候曾经有美国客户弹吉他给我们听,更多的则是会和我们的工程师聊文化,聊美食,聊音乐,甚至最后谈到人生理想,全程都无须费心。

 

升级结束之后,健康检查也显示一切正常,这时发生了一个小插曲,XtremIO的图形化管理界面XIO Client无法正常打开。这里也给大家科普一下,3.x到4.x作为跨版本的升级,图形化管理界面在升级后也有所改动,只需重新在浏览器中键入XMS IP地址,而后依照提示,便能重新打开管理界面。

 

由于客户的升级时间安排在非工作时间,升级结束已经是晚上10点了,忽然听得传来一声感慨“已经连续一个星期没回家吃晚饭了”,在这里也深深的感受到了现场工程师的不容易。

 

步出机房,这个美丽的城市华灯初上,一切似乎才刚刚开始。

 

 

 

 

作者信息:

郑水亮(Derek Zheng

亚太地区上海远程变更管理团队(Remote Proactive Team)升级工程师, 负责XtremIO相关产品的升级工作。

Ensure all servers attached to your storage array have storage path management software, such as EMC PowerPath, that is correctly installed and configured for path failover. EMC recommends Round Robin path selection policy for XtremIO

 

相信大家在EMC 最佳实践文档中见过以上内容,简而言之,EMC推荐使用“Round Robin”作为NMP Policy以确保XtremIO升级的正常进行。

 

首先,我们来看看NMP到底是个啥玩意儿?

NMP =  Native Multipathing Plug-IN, 中文名为“本机多路径插件”。

其一共有三种模式,分别为 MRU,Fixed, Round Robin。

MRU (Most Recently Used): 最近使用策略,当系统启动后,第一个被发现可以工作的路径,如果不行,就一直试到好用的一条路径为止。当原路径恢复后也不会回切。适用于存储类型为Active/Passive主备模式。

Fixed: 固定策略,也是开机后的第一条可用路径,如果失效的链路恢复,会采取回切。适用于存储类型为Active/Active的模式。

Round Robin(RR):循环策略,以轮询的方式选择所有可用路径,这是最佳实践推荐的模式,但并不是所有存储都支持这种策略。

 

介绍完了NMP,我们就赶紧步入正题,一步一步来教你设置NMP。

 

第一步:选择“配置”

 

第二步:选择“存储器”

11.jpg

第三步:右键选择“属性”

22.jpg

第四步:选择“管理路径”

33.jpg

 

第五步:选择“循环”

 

以上,Round Robin已经设置完成,是不是很简单?那还等什么,赶快去教男神设置NMP吧。

 

今后还会定期推出老司机系列,所有内容都将会更新在首页“实战教程”中,敬请期待哦。

不知道为什么,我的微博有时候会很卡,比如刷新时会一直Loading(见图1)。这不只是我的个人感受,很多网友都抱怨过。而装在同一个手机上的微信,连的也是同一个Wi-Fi,却没有这个症状。虽然这个问题出现的并不频繁,但假如我是微博的开发人员,肯定要把原因找出来。

1.png

1

当我的手机抓包环境搭好时,第一个想解决的问题就是这个。我随意发了一条微博,虽然没有碰到卡顿,但还是把包抓下来了。开头几个网络包如图2所示。

2.png

2

我又发了一条测试私信,可惜也没有卡顿。开头几个网络包如图3所示。

3.png

3

虽然两次都没有重现问题,但是从网络包可见,微博的工作方式严重依赖DNS。它在调用任何功能之前都要先向DNS服务器查询,得到提供该功能的服务器IP,然后再建立TCP连接。最神奇的是它不会缓存查询结果,所以需要频繁地重复查询DNS。我才抓了两分钟包,竟然就看到了上百个查询,这会不会就是微博卡顿的原因呢?我又抓了一个发微信的包作对比,如图4所示。

4.png

4

果然,微信客户端直接就和一个IP地址建立了连接。不管这个IP是写在配置文件中的,还是之前就存在手机的缓存里的,这至少说明了微信不像微博那样依赖DNS

为了进一步验证这个猜测,我故意把手机上的DNS服务器配成一个不存在的地址。不出所料,微信还是能照常工作,但微博就再也刷不出来了。之前我手机上配的DNS服务器位于美国,可能有时候跨国连接不稳定,所以导致了微博的卡顿现象。考虑到这一点,我尝试配了一个国内的DNS(见图5),果然从此再也没卡过了,刷起来异常流畅。

5.jpg

5

当你看到这篇文章的时候,也许这个问题已经被新浪解决了,因为我已经向微博的技术人员反馈过(或者他们早已经知道)。相信解决起来也不复杂,只要像微信一样缓存IP就可以了。据我所知,苹果的App Store和小米电视也遭遇过DNS导致的性能问题,所以相信还有很多设备或者程序可以利用Wireshark来优化,只要把使用过程的包都抓下来,说不定就能发现值得改进的地方。

最后再补充一个小发现。我发的微博内容是“capture test, will delete it soon.”,分享范围设成“仅自己可见”。没想到在Wireshark上直接就看到了明文(见图6底部),发私信就没有这个问题。因此我们连公共WiFi发微博的时候,还是要小心一点。不要以为设成“分组可见”或者“仅自己可见”就够私密了,其实在Wireshark上都能看到。

6.png

6

 

作者信息:

林沛满

林沛满是一位有近十年存储经验的技术专家,擅长文件存储的性能分析、归档和备份。同时也专注于网络协议分析,比如CIFS/NFS/HTTP/TCP/UDP等,是《Wireshark网络分析就这么简单》、《Wireshark网络分析的艺术》等书的作者。

 

注:本《大咖讲网络》系列文章取自《Wireshark网络分析的艺术》一书。

MTU带来的问题实在太多了,但凡做过运维、实施或者技术支持的工程师,或多或少都会遇到。一个典型的MTU问题发生在类似图1的环境中,即两个子网的MTU大小不一样。

pic1.png

1

当客户端发给服务器的巨帧经过路由器时,或者被丢包,或者被分片。这取决于该巨帧是否在网络层携带了DFDon’t fragment标志。如果带了就被丢弃,如果没带就被分片。Wireshark上很容易看到DF标志,如图2中的方框内所示。分片的情况往往被忽略,因为它只影响一点点性能,大多数时候甚至察觉不出。丢包的情况就无法忽略了,因为丢包之后再重传多少遍都没用,会一直丢,整个传输就像掉进了黑洞,所以往往会导致严重的后果。

pic2.png

2

我有个实验环境恰好就是图1这样的,可以来做个实验加深理解。我从客户端给服务器发送了两个ping请求,第一个携带1472字节,第二个携带1473字节,并都用了“-f”参数设置了DF标志。命令及结果请看图3,第一个ping成功,第二个则失败了。

pic3.png

3

由于ICMP头为8字节,IP头为20字节,所以第一个ping请求在网络层的长度为1472+8+20=1500字节,第二个ping请求则为1473+8+20=1501字节。我的路由器MTU1500字节,不难理解第一个ping请求的长度没有超过MTU,所以可以传输成功;而第二个ping请求的长度超过了路由器出口的MTU,又不允许被切分,所以不能传输成功。在图3底部可以看到路由器提示了“Packet needs to be fragmented but DF set”。

这个过程的网络包可以从图4中看到,请注意最后一个包是路由器回复的“Fragmentation needed”,而不是服务器回复的。假如ping的时候没有用“-f”设置DF标志,那么1473字节也是能ping成功的,只是在路上会被切分成两个包。

pic4.png

4

理论说起来很简单,实验做出来也不难,但在生产环境中的症状就没这么明显了,要发现MTU问题往往需要一些想象力。我收藏了不少MTU相关的案例,在本文挑出三个最有代表性的来分享。

案例1 用户浏览某些共享目录时客户端会死机,浏览其他目录则不会。

碰到这种症状,恐怕没有人会想到是MTU导致的,所以经过长时间徒劳无功的排错之后,工程师不得不抓了个包。这个包是在服务器上抓的(因为客户端死机,根本没法抓),如图5所示,服务器回复的包“Seq=193Len=1460”在持续重传,但客户端一直没有确认,似乎是发生丢包了。从图5底部还可以看到这个包携带的信息是该目录的子文件(夹)列表。

pic5.png

5

 

导致丢包的可能性有很多,我为什么认定是MTU导致的呢?推理过程如下。

1.如果端口被防火墙阻止了也可能丢包,但是会从三次握手时就开始丢,而不是等到浏览目录的时候。

2.如果网络拥塞也可能丢包,但一段时间后能恢复,而不是这样持续地丢。

3.丢的那个包携带了1460字节(相当于占满了整个1500字节的MTU),算是比较大的。而没被丢弃的2号包和4号包都携带了很少的字节数,只丢大包的症状说明很可能就是MTU导致的。

4.我用“ping <server_ip> -l 1472 -f”测试,果然失败了。逐渐减小每次ping的长度,到了1400字节左右才成功,这说明网络上有个设备的MTU比较小。

5.于是把服务器上网卡的MTU相应改小,问题果然就消失了。

6.之所以浏览其他目录没有死机,可能是因为这些目录中的子文件(夹)比较少,凑不满一个大包。

我曾经访问公司内网时出现问题,在抓包里也看到类似于图5的症状,后来也是通过修改MTU解决的。

案例2 客户端的MTU1500字节,服务器端的MTU9000字节,平时连接正常。运维人员听说两端的MTU最好一致,所以把客户端的MTU提高到9000字节,没想到连接反而出问题了。

虽然该案例听上去不太科学,但如果网络路径上有个设备的MTU1500字节,这个问题就真会发生。原先客户端和服务器在三次握手时,双方会“协商”使用一个1460字节(MTU-TCP-IP头)的MSS,所以可以顺利通过那个MTU1500的网络设备。如果两端都是9000字节了,那三次握手时就会得到8960字节的MSS,因此通不过那个网络设备。

案例3 无法完成Kerberos身份认证,在客户端抓到的包如图6所示。

由图6可见客户端在持续地向KDC发送TGS-REQ,但是收不到任何回复。本来碰到这种情况最好在KDC上也抓个包看看的,但是KDC一般不让人登上去。怎么办呢?

pic6.png

6

从这几个网络包里是挖掘不出更多线索了,我们只能推测哪些因素会导致TGS-REQ得不到回复。有一个可能是端口被防火墙封掉,但那样的话之前的其他Kerberos包(比如AS-REQ)也得不到回复,不可能走到TGS-REQ这一步,因此防火墙可以排除。还有一个可能就是MTU导致的丢包了,假如网络路径上有个交换机的MTU偏小,大包无法通过就可能出现此症状。仅从Wireshark中我们无法判断是客户端发给KDC时丢包了,还是KDC回复客户端时丢包了,只能先试着把客户端的MTU改小一点,问题果然就消失了。其实利用“ping -f -l <字节数>”试探出路径上的最小MTU也可以,前提是网络中没有禁用 ICMP

Filter Blog

By date:
By tag: