Find Communities by: Category | Product

有位读者在豆瓣上评论我的上一本书,说有阅读侦探小说的感觉。我对此并不觉得惊讶,因为Wireshark排查问题,和侦探破案的思路是一致的。神探福尔摩斯的破案秘诀是“溯因推理”先观察所有细节,比如鞋根上的泥疙瘩甚至烟灰;然后作出多种推理和假设;接着刨去各种不可能,最后剩下的“无论多么难以置信,肯定没错。”用Wireshark分析网络包时也类似,我们先要在网络包中寻找各种线索,然后根据网络协议作出推理,接着刨去人为(有意或无意)掩盖的证据,才能得到最后的真相。尤其是和保密机构打交道的时候,工程师进不了机房,文档也不能公开,所以一切线索只能自己在包里找,感觉就更像破案了。

我最近帮一位读者解决的问题就非常典型。他供职的机构内部网站有时候会发生诡异的现象,比如Web服务器的端口号会随机发生变化(具体症状就不多讲了,和本文关系不大)。后来做了排查,把客户端和Web服务器直连,问题就消失了,确认了Web服务器和客户端都没有问题。难道根本原因就出在网络路径上了?可是管理员又声称网络拓扑非常简单,不会出问题的。见图1客户端和Web服务器在不同的子网里,中间由一个路由器转发

111.png

1

凭我的经验,这个网络拓扑的确简单到没有出问题的可能。可是已经到了山穷水尽的地步了,只好抓包试试。Web服务器不允许我们登录,所以只能在客户端抓,更糟糕的是抓包时那个诡异的现象并没有发生。你一定会纳闷,正常状况抓的包有什么看头啊?人在走投无路的时候,要求都是很低的,能抓到一点算一点。图2就是抓到的包,看起来一切都很正常:前3个包是三次握手,接着客户端发了个HTTP GET请求,服务器也确认收到了。

222.png

2

既然表面上都是好的,我们再看看每个包的详细信息。1号包的详情见图3,客户端把包交给了一个叫c0:62:6b:e2:bd:88MAC地址,该地址属于默认网关。将包交给默认网关是合理的,因为Web服务器在另一个子网中,需要路由转发。也就是说,从1号包中没有发现任何异常。

333.png

3

再看看图42号包详情。这个包让人眼前一亮,信息量实在太大了。在阅读下面的文字之前,建议你自己先在图中找找亮点。

444.png

4

首先这个包竟然是从MAC地址00:10:f3:27:61:86发过来的,而不是之前提到的默认网关c0:62:6b:e2:bd:88。我不知道这个MAC地址属于什么设备,但这至少说明2号包和1号包走了条不一样的路径。再看其Time to liveTTL)居然是64,理论上经过一次路由的包,TTL应该减去1,变成63才对。根据这两条信息,可以推测管理员提供的拓扑图有误。真正的网络包流向应该接近图5即客户端发出去的包是经过路由的,而Web服务器发过来的包没经过路由

555.png

5

其实到这里就可以去找管理员说理了,不过别急,继续往下看。到了图6的第5号包,发现Identification竟然是49031,而同样是来自Web服务器的2号包(见图4)中,Identification却是0。一般发出Identification0的机器永远都发0,不会一下子跳到49031。也就是说,其实2号包和5号包是两台不同的设备发出来的,这意味着在Web服务器和客户端之间,可能存在一台设备在代理三次握手,而能够代理握手的设备很可能是应对Syn flood攻击的防火墙。

666.png

6

因此图5的拓扑图还不够准确,应该更正成图7的样子。管理员忽视了这台防火墙,可能就错过了发现问题根源的机会。

 

777.png

7

把以上分析反馈给管理员之后,他果然通过MAC地址00:10:f3:27:61:86找到了一台防火墙。也正是防火墙上的一些错误配置,导致他们遇到了那些诡异症状,改正之后症状就消失了。本文的目的是演示如何在网络包中寻找被掩盖的线索,而不是防火墙知识,所以就不展开了。

从头到尾再复习一下整个过程,是不是很有当侦探的感觉?

 

注意:为了保护客户隐私,本文截图里的IP地址和MAC地址都被PS过,这就是为什么有些截图看上去不太自然。

EMC Symmetrix系列是高端存储的一个重量级的产品,同时也是EMC最重要的产品之一。做为新一代的企业级存储,能为越来越多具有苛刻存储需求但资源有限的 IT组织和服务提供商提供高端虚拟存储功能。 symmetrix 总共有20多年历史, 一共有接近7代的产品线, 支持所有主流的操作系统.支持open systemmainframe.支持多种环境,具有非常强大的性能,扩张性和可用性. 1具体介绍了Symmtriex的发展历史。

Capture1.PNG.png

                           图1

Symmetrix VMAX作为 Symmetrix系列的最新成员,具有强大革新性的 Virtual Matrix Architecture横向扩展体系结构。VMAX提供了可扩展的性能、简化的管理与资源调配、自动分层、本地复制与远程复制,并且能够同时支持来自 VMware和其他供应商的数千个虚拟机。本文接下来将主要介绍Symmetrix VMAX独具特色的FAST(Fully Automated Storage Tiering)-- 全自动分层存储.

 

全自动分层存储简介

VMAX的自动存储分层(Fully Automated Storage Tier, FAST)的主要功能就是提升存储效率,同时通过减少昂贵存储设备的使用降低总体成本。它可以帮助将那些相对不常访问的数据由昂贵的固态硬盘或者光纤磁盘设备无缝迁移到相对廉价的SATA盘或者近线SAS盘上。

2.png

                                           图2

总的来说FAST 可以优化性能、成本和占用空间,使 IT 组织能够在较小的占用空间中更有效地管理更多信息。同时也能帮助企业降低电力和冷却成本、资金成本及运营成本。因此,与传统系统相比,它拥有更高的性能、更低的成本和更密集的占用空间。 通过 FAST,企业级闪存驱动器会帮助应用程序性能提高达 800%,并使串行高级技术附件 (SATA) 磁盘驱动器的成本降低高达 80%。


FAST基本工作原理

FAST是根据LUNSubLUN级别的负载情况,将访问频率高的数据迁移到高性能的磁盘,访问平率低的数据迁移到高容量的磁盘。FAST VP 主要由两部分组成:

  • Symmetrix微码:控制磁盘阵列各个部件的Enginuity存储操作环境的一部分。
  • FAST控制器:SP上运行的一项服务。

3.png

                        图3

FAST VP 处于激活状态下时,微码和FAST控制器会执行两套算法:

  • 智能分层算法(Intelligent Tiering Algorithm)主要是在FAST VP的控制下,利用sub-LUN的指标数据为需要迁移的数据选择适当的存储层。FAST VP会结合近期和远期参数统计数据,自动优化数据的读取功能,进而实现低成本的效益。总的来说智能分层算法就是一个数据移动请求的集合,并且这些请求最后都会被提交到VLUN VP 数据迁移引擎,实现最终的数据移动。分配合规算法主要是通过FAST策略里规定的最大使用容量,用来监测存储虚层中容量的使用情况
  • 分配合规算法(Allocation Compliance Algorithm)则由FAST控制器生成,通过微码并按照设定好的FAST策略来执行。

如图-3所示。智能分层算法利用微码收集到的指标数据,同时结合FAST控制器提供的运算结果,向Vlun VP数据移动引擎发出数据迁移的请求,然后根据数据存取频率的高低,将较的数据移到高速存储层,并将较不活跃的数据转移到低速存储层

由于追踪统计分析与数据迁移作业,都会消耗磁盘阵列控制器的资源,FAST VP为此专门提供预设操作功能,允许设定执行统计分析与数据迁移操作的时间区段,尽量避开数据存取的高峰时段。  比如可设定为只允许在晚上7点以后、或周五晚上到周日凌晨等下班时段,执行分析与迁移操作。

 

FAST VP 的配置

Symmetrix VMAX上运行FAST VP前,需要配置好:存储组, FAST 策略 以及虚拟池 VP Tiers);

  • 存储组是Symmetrix 逻辑卷的集合,通过关联相应的应用程序实施统一管理;
  • FAST 策略包含了一系列应用于一个或多个存储组的Tier使用规则;
  • 虚拟池 VP Tiers)包含了14个存储池以及RAID的保护类型;

FAST策略会收集每个Thin设备的LUNsub-LUN的统计数据。这个数据收集主要是由Symmetrix的微码在用户先前设定好的时间断执行。数据参数的收集则和Symmetrix的后端活动有关,因为这个涉及到服务器的I/O量。通过测定Symmetrix后端的I/O,进而判断数据的访问频率,这样FAST VP 就能够决定不同数据组里每个Thin设备的数据迁移。访问频率高的数据,会被移动高性能的磁盘(SSD),访问频率低的数据将被移到底层的低速存储。

4.png

                       图4

FAST VP 的运行模式 及常用命令

FAST VP 有两种运行模式,自动(Automatic)或者 关闭 Off)。自动模式下,系统会在预先设定好的时间段执行统计分析与迁移操作。关闭模式下,系统会继续收集统计分析数据,但是不会发生任何数据的迁移。

这里向大家介绍三条比较常用用于管理FAST VP SYMCLI命令:

symfast, symtier, and symsg

  • 建立一个存储组 “VP_ProdApp1”

symsg –sid 1849 create VP_ProdApp1

  • “VP_ProdApp1”存储组中添加存储设备:

symsg –sid 1849 -sg VP_ProdApp1 addall devs –range 100:104

  • 为保护类型为RAID5EDF创建一个虚拟池:

symtier –sid 1849 create –name RAID5_EFD_Tier –tgt_raid5 –tgt_prot 7+1 –technology EFD –vp –pool R5_EFD_Pool

 

  • 创建一个名为 Platinum 的策略

symfast -sid 1849 -fp create -name Platinum

  • FAST策略添加Tier,并设定25%的用量:

symfast -sid 1849 -fp -fp_name Platinum add -tier_name RAID5_EFD_Tier -max_sg_percent 25

  • 最后将存储组与策略关联:

symfast -sid 1849 -fp_name Platinum associate -sg VP_ProdApp1 -priority 2

 

客户可以根据上述SYMCLI命令来创建管理FAST VP

 

升级对FAST VP的影响


一般来说只要数据没有发生迁移,微码的升级是不会对FAST VP产生任何影响。作为升级工程师,在升级前,都会检查FAST VP当前的状态。在确定没有发生数据迁移的前提下,升级工程师都会先暂停FAST VP,等到升级结束后,在重新启用。

如果FAST VP正在执行数据迁移(如图-5所示),那么升级只能等到数据迁移结束后才能实施。因为这个时候升级会导致先前收集到的指标数据全部丢失,系统将无法判断数据的冷热程度,而且FAST VP将花费大量的时间需要重新开始收集指标数据。这些都会对阵列的性能造成一定的影响。数据迁移的时间由迁移数据量的大小来决定,一般是在24-48小时之间。

5.png

                                    图5

联系方式:

如果有意愿对您的Symmetrix阵列进行升级,请随时与RemoteProactive@emc.com 联系预约。

 

如果有任何问题请联系我们:

邮箱:RemoteProactive@emc.com

电话:+1-800-782-4362 x 6305555

网上在线支持: https://support.emc.com  Live chat


作者简介:

Steven Xu

DSC08518.JPG.jpg

亚太地区上海远程变更管理团队(Remote Proactive Team)升级工程师,熟悉Symmetrix基本工作原理,能够及时解决升级过程中出现的相关问题,并多次获得客户好评。目前主要负责Symmetrix, Isilon 和XtremIO产品的升级工作。

大咖前言

 

在过去几年中,有不少读者、同事和网友向我咨询过网络问题,其中大部分都记录在案。我一直把这些案例视为珍贵的财富,因为既真实又有广泛的代表性,比我自己在实验室中“制造”出来的好多了。本书人中选择了最经典的部分,希望读者会感兴趣。如果你在工作或生活中遇到网络问题,也欢迎抓个包来找我分析。



Linux为什么卡住了?

 

到今天为止,已经有5位读者向我求助过这个问题了。症状请看图1,他们通过SSH登录Linux服务器时,输完用户名就卡住了,要等待10秒钟才提示密码输入。这究竟是什么原因导致的呢?其实我也是Linux菜鸟,虽然尝试过搜索“ssh hang”等关键词,但是没找到相关信息。

111.png

1

10秒钟的时间并不算长,吃个薯片喝口咖啡就过去了。但是作为强迫症患者,我还是容不得它的存在,因此便决定写篇文章,向大家演示一下怎样用Wireshark一步步解决这个问题。

首先是抓包,步骤如下。

1.在Linux服务器上启动抓包。

2.从笔记本SSHLinux服务器,输入用户名并回车。

3.等待10秒左右,直到登录界面提示输入密码。

4.停止抓包。

这样就可以得到一个涵盖该现象的网络包了。一般在实验室中没有干扰流量,不用过滤也可以分析,不过我们最好在做实验时就养成过滤的习惯,以适应生产环境中抓到的包。因为我们是通过SSH协议登录的,所以可以直接用“ssh”来过滤,如图2所示。SSH包都是加密了的,因此我们看不出每个包代表了什么意思,不过这并不影响分析。从图2中可以看到,21号包和25号包之间恰好就相隔10秒。


222.png

2

这两个包之间所发生的事件,可能就是导致这个现象的原因。于是我再用“frame.number> 21 && frame.number< 25”过滤,结果如图3所示。

333.png

3

从图3中可以看到,Linux服务器当时正忙着向DNS服务器查询10.32.200.23PTR记录(即反向解析),试图获得这个IP地址所对应的域名。该IP属于我们测试所用的笔记本,但由于DNS服务器上没有它的PTR记录,所以两次查询都等了5秒钟还没结果,总共浪费了10秒钟。

我们由此可以推出,这台Linux服务器在收到SSH访问请求时,会先查询该客户端IP所对应的PTR记录。假如经过5秒钟还没有收到回复,就再发一次查询。如果第二次查询还是等了5秒还没回复,就彻底放弃查询。我们甚至可以进一步猜测,如果DNS查询能成功,就不用白等那10秒钟了。

为了验证这个猜测,我在DNS服务器中添加了10.32.200.23PTR记录,如图4所示,然后再次登录。

444.png

4

这一次果然立即登录进去了。从图5Wireshark截屏可见,DNS查询是成功的,所以21号包和26号包之间几乎是没有时间停顿的。

5

明白了DNS查询就是问题的起因,接下来就知道怎么进一步研究了。只要在Google搜索“ssh dns”,第一页出来的链接都是关于这个问题的。随便挑几篇阅读一下,就连我这样的Linux初学者都能把这个问题研究透了。原来这个行为是定义在“/etc/ssh/sshd_config”文件中的,默认配置是这样的:

[root@Linux_Server ~]# cat /etc/ssh/sshd_config |grep -i usedns

#UseDNS yes

改成下面这样就可以解决了,不用去动DNS服务器上的配置:

[root@Linux_Server~]# cat /etc/ssh/sshd_config |grep -i usedns

UseDNS no

我经常说技能比知识更重要,这就是例子之一。学会了使用Wireshark,其他知识也会跟着来的。


作者简介:

 

林沛满


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

Filter Blog

By date:
By tag: