Find Communities by: Category | Product

1 2 3 Previous Next

工程师手记

159 Posts

今天我们来聊一聊Thin Provision的概念。

 

据姿姿了解,这种技术在各个平台的存储内得到了广泛的应用。

与VMware对VMFS的thin provision类似,(他有三种设备形式: thin, zeroedthick, eagerzeroedthick)symmetrix也适用了这样的技术。

 

本文着重介绍Sym内部的thin provision

 

中文翻译过来叫受供给。

1.jpg2.png
不对。

瘦供给。

怎么理解呢?

 

把它理解成完全虚拟的东西,它呈现给你的只是表面,真正的用于存储数据的还是在thin device后面的data device。

来看下面的图:

640.jpg

 

左半部份的Thin device就是直接呈现给客户主机的设备。主机可以看到并且访问的就是thin device。

创建方法如下(通过Solutions Enabler):

create dev count=n, size=n, emulation=xxx, config=

通过这样的命令可以创建任意大小的和数目的thin device。是不是很开心?

 

继续往右看:

看到有多个Data device。

这个就不是thin那么假的东西了,而是实实在在存数据的设备。这个device是不能被客户主机看得到的。

 

有两个Pool-池子。池子就是用来存放多个Data device的东西。一般来说一个池子内的盘的类型最好一致,这是为了更好的性能。相信大家知道symmetrix内有一个FAST的功能,将热数据移动到性能强劲的EFD盘,冷数据移动到性能一般的SATA盘,中间层留给FC的盘,这样自动的调度数据以保证存储的良好性能。那么在FAST这个特性里面就是通过把同类型的盘放到一个池子里,进行了数据迁移。

 

好像扯到FAST上去了,回来。。

 

就像上面的图片那样,thin device通过一种bind的操作,绑定到后面的一个特定池子。接下来主机发来一个写数据的命令下来,数据会找到与thin device绑定到的池子,然后并行的写到整个池子的data device内。

 

既然提到了bind,顺便也介绍一下Solutions Enabler的命令。

bind tdev symdevname in DG dgName to pool PoolName;

 

在做thin device与pool的绑定操作时,可以做一种叫preallocate的操作。也就是预先分配。正常来讲,只有当数据写下来时才会给thindevice分配实际的数据空间。预分配的设定下,系统会先分配一定的空间给到thin,数据写下来时直接使用预分配的空间。

 

 

ok数据该写的写下来了,空间该用的也用完了,满了咋整?

 

2.png
别怕~再加device到pool里呀

我们假设现在有一个32device的大池子。但是即将达到近95%-100%的状态,这时候可以再加一定数量的设备到池子里面。

3.jpg

 


如上图。

 

姿姿建议再做一个rebalance的操作:将部分数据从已经使用的设备迁移到新加入的设备。因为在数据写入池子里时,它会把数据平均下来写给每一个设备。加入之前的设备已经被数据撑满,那么新数据写入池子里时它们只能写到新的设备,这样明显出现了性能问题。

 

4.jpg


还可以通过一种操作实现这个功能:Drain

通过Drain操作可以排空一个Datadevice内的所有数据,并将数据移到其他的data device里面,以达到0%使用率的data device的目的。

操作过程如下:

1, 首先deactive老的32个device,这种操作之后不会有新数据写入这些设备。

5.jpg

2, 对这些32个设备执行drain操作,(每次只能执行五个,需要分批执行)

在此过程需要实时的计算最佳的使用率,这些data device的使用率达到预期的瞬间,终止drain的操作。(由于新数据一直写到了新加入的16块盘,整个pool内的设备使用率会达到相对的均匀分配)

 


今天就讲这么多。


 

作者信息:

 

Kevin Li(李启明)

3年Symmetrix技术支持经验

熟悉SRDF架构以及相关解决方案

1. 原理


1.1 SRDF复制模式


  • 复制模式
    • 同步复制:Synchronous Replication SRDF/S)
    • 异步复制:Asynchronous Replication (SRDF/A)
    • 自适应拷贝复制:Adaptive Copy Replication
  • 复制模式可以动态更改
  • 操作方法可以按设备指定
  • 性能、同步级别和I/O序列化要求决定采用哪种操作模式合适
  • 所有复制模式可以在Symmetrix阵列内共存


1.2 SRDF/A主机写IO处理


            当源盘阵收到数据立刻反馈给主机,主机可以继续写入,不保证数据是否已在目标盘阵

1.png

    数据变动保存在源盘阵内存

2.png

    达到传送周期即打包发送给目标盘阵

3.png

          形成新的周期数据包

4.png

1.3 常见的SRDF/A连接


  • 通过IP广域网连接
    • 距离远
    • 中间链路稳定性低于FC

5.png

1.4 SRDF/A对于链路抖动等的处理机制


  • Link Limbo: 单条链路,短期中断
    • 缺省10
  • Transmit IdleSRDF/A组中所有链路中断
    • 数据传输中断
    • R1盘阵缓存需要传输的数据,达到内存上限则将session suspend
    • 应与DSE共用,用硬盘辅助缓存数据
  • Write Pacing:延长主机写IO响应时间避免内存超限导致的SRDF/A中断
    • Group-level
    • Device-level:用于RDF设备同时参与TimeFinder操作的场景
  • Tolerance Mode:临时设置,在性能与数据一致性间加以平衡
    • 允许若干设备在R1NRR2RWSRDF/A仍为active
    • 此时R2数据的一致性不予保证
    • MSC不支持


1.5 SRDF/A对于内存占用的限制


  • SRDF/A占用内存上限
    • Write Pending Limit
      • 5875之前:盘阵可用内存的80%
      • 5875及之后:在binfile中设置Cache Allocation Policy参数,为可用内存的50%~75%
    • SRDF/A cache usage limit: SRDF/A可用内存占WP的百分比,VMAX缺省为74%VMAX之前缺省94%

ExVMAX WP 75%SRDF/A 74%SRDF/A可用总内存的55.5%

  • SRDF/A组优先级:在内存资源不足时先放弃优先级较低的组
    • 0-FF,缺省80
    • 数值越低,优先级越高


1.6 VMAX3SRDF/A的改进


  • VMAX3单个SRDF/A的组就可以产生多个cycle,小cycle易于完成传输,有利于及时释放内存
  • Multi-cycle mode环境:VMAX3 – VMAX3
    • R1: one capture cycle, multiple transmit cycle
    • R2: one receive cycle, one apply cycle
  • 典型案例
    • R2盘阵内存小于R1盘阵内存
    • 链路丢包较多

 

2. 管理界面及错误信息


2.1 Unisphere for VMAX图形界面


Solutions Enabler提供了命令行界面管理SRDFUnisphere for VMAX提供了图形界面,例如下图。

6.png

2.2 Enginuity错误信息


例如:

  • 047D                – one link lost
  • 046D                – all links for a group lost
  • 047E                – A single link has been gained
  • 046E                – All links in an RDF group have been regained
  • CACA   – SRDF/A session drop due to non-user requests


2.3 symevent错误信息


例子:

  • 单条链路断
  • 组内所有链路断组将会进入suspend状态
    • 如果配置了transmit idle,将首先进入transmit idle状态

7.png

  • 内存超限

8.png

3. SRDF/A常见中断原因及解决


除了前面所说的链路问题,SRDF/A常见的中断原因是需要传输的数据超出了传输链路带宽,数据积压占用内存达到上限而自动中断。当然,盘阵性能问题导致占用内存过多也会有相同的结果。

  • 传输带宽不足:增加传输链路带宽
  • 短期带宽不足:DSE
  • 盘阵性能问题:解决性能问题


3.1 链路带宽不足

9.png

  • 配置
    • B点到C点间为SRDF/A
    • 3对盘阵的SRDF/A远程复制共用带宽为622Mb的专线。
  • 问题
    • 某一台盘阵的SRDF/A组经常在17:30左右宕掉
  • 原因
    • 取性能数据检查,在17:30开始经常出现所有SRDF/A组的流量需求总和超过90MB/s,即720Mb/s的现象,超过了链路带宽
    • 由于在高峰时段链路带宽不足,导致SRDF/A组断掉

时间点

所有组流量需求总和

11/12/2013 17:20

  1. 87.94

11/12/2013 17:25

  1. 94.59

11/12/2013 17:30

  1. 71.96

11/12/2013 17:35

  1. 73.58

11/12/2013 17:40

  1. 79.58

11/12/2013 17:45

  1. 79.58

11/12/2013 17:50

  1. 78.46

 

  • 解决
    • 增加链路带宽

3.2 短期带宽不足

10.png

11.png

  • 问题:从性能数据看,SRDF/A流量突增,然后整个groupoffline了。
  • 日志分析:从盘阵日志看到,出现CACA.10错误,意味着盘阵的内存使用超出限制,主动中断SRDF/A
  • 情况分析:
    • 峰值时间很短
    • 未使用DSE
    • 后端资源不忙
  • 结论:建议使用DSE

下面是使用DSE后的性能图表。

12.png

  • 解决:同样的盘阵,在使用DSE之后,从SRDF/S group 206短期传来大量数据需要通过SRDF/A group 207传输到远程灾备盘阵,可以看到DSE缓存了大量数据,SRDF/A group 207在接近传输上限的程度运行了一段时间,但SRDF/A group并未中断。

3.3 链路问题导致内存超限


  • 日志分析:
    • 16:30报错显示cycle number已经一个小时没有切换

13.png

    • 23:44报错显示内存超限导致SRDF/A中断。从性能数据看当时Write Pending达到79%

14.png

  • 性能数据分析:15:30开始,cycle number不再增长,但rdfa的状态仍然是active,之后,active cycle size持续增长,占用内存也持续增长,一直到23:45时变成了inactive

15.png

16.png

  • 原因:链路质量问题导致R2无法正常接收cycle,导致cycle size持续增长,最终超过Cache usage limit
  • 解决:修复有质量问题的链路。

众所周知,NetWorker可以在备份组结束后自动发起克隆任务。这样对于有数据多份要求的客户有很多的便利,他们可以保证每次的备份数据都可以正常保存两份。而且他们不需要去单独配置克隆任务或者发起克隆命令。

 

那么NetWorker会根据什么设置去执行克隆作业呢?大家都知道在组属性中我们可以选择在备份执行后发起克隆,发起的方式有如下图两种:

 

克隆模式:

Start on each save set completion

Start on group completion

nw1.png

 

 

那么我们就根据这两种不同的配置来解释一下克隆的工作原理

Start on Group Completion

==========

1. 克隆任务在该组所有备份任务完成后发起。

2. nsrclone发起之前,备份服务器会去检查备份的媒体数据库来确认需要克隆哪些存储集

3. 备份服务器的媒体数据库通过这个检索规则来确认只有最近的备份数据才会被克隆任务执行:“save set start time” >= “save group start time”

4. 但检索媒体数据库完成,所有需要克隆的存储集的SSID都会被返回给nsrclone。如下面命令行:

nsrclone -s bdi-prd-nwk.corp.danamon.co.id -v -D 5 -b ddboost_sql_bsd_clone -C 1 -S -f < 497909124 514686338

 

所以我们需要明白克隆的完成需要同时参考客户端和服务器。“save set start time”这个参数是由备份客户端提供的,也就是客户端启动备份的时间。但是“save group start time” 这个参数则是由备份服务器提供。这个是备份组发起的时间。如果备份服务器和备份客户端之间的时间有差异,那么就可能会出现有些数据不会被克隆的情况。 也就是我们常说的数据丢失。

 

 

如果需要了解媒体数据库检索的具体情况,可以对nsrd开启-D5或者以上,结果会返回检索命令。

On Each Saveset Completion

==========

1. 在备份组发起的时候,克隆任务就发起来了。

2. 一个临时文件会创建出来作为克隆的源文件。默认路径是:\\nsr\\tmp\\sg\\<groupName>\\<.groupName>

3. 命令nsrclone会根据下面的参数来运行:

nsrclone -s bdi-prd-nwk.corp.danamon.co.id -v -D 5 -b ddboost_sql_bsd_clone -C 1 -i "D:\\Program Files\\EMC NetWorker\\nsr\\tmp\\sg\\PRD-Adhoc-SQL-Cumulative\\.PRD-Adhoc-SQL-Cumulative" -g PRD-Adhoc-SQL-Cumulative

4. 每当一个save任务运行结束,就会把SSID写入到\\nsr\\tmp\\sg\\<groupName>\\<.groupName>

5. 在备份组完成之后,这个临时文件就会被删除。

 

所以为了保证克隆精确完成,我们必须保证在组启动前这个临时文件不存在,同时在组备份成功完成后这个临时文件不再存在。同时如果我们对于克隆的存储集有疑问,也可以打开这个临时文件检查。

 

 

Mandy Xu

Technical Support Engineer, NetWorker

Dell EMC | Customer Service

 

今天看到了一组很有趣的调查数字。

 

80% of companies say they deliver superior customer service. Only 8% of customers agree.

大概有80%的公司都宣称自己为客户提供了无与伦比的服务,但是只有8%的客户同意这个观点。

 

那么,到底是为什么让92%的客户都抱持“呵呵哒” 的态度哪?

因为我们经常自欺欺人,以为自己给的就是最好的,自己给的就是客户想要。

 

RPS作为服务客户的一线部门,一直以来致力于为客户提供专业的服务,以客户的满意度为依归。除了客户满意度调查外,在部门内还有定期更新的名人墙,更加直观地反映了客户对服务中点点滴滴的看法和感受。




下面为大家节选两段来看看客户是怎么评价RPS的服务的:

 

Summer & Ten - 今天他们所表现出的服务水平相当出色,每个人都很熟悉他们的分工,处理意料之外状况的流程非常迅速。

 

Mika - 即使是同样的升级工作,也让我们意识到了EMC的技术支持相比较这个世界上其他IT供应商而言是多么的专业。

 

大家就不要尝试寻找小编了,大多客户对小编的评价都是“腿很长”,“长得像宋仲基”,这样的评价扶不上墙啊。(宝宝心里苦,但宝宝不说〒_〒)

老司机又来了, 今天要讲的是VAAI。

 

 

Ensure all ESXi hosts attached to your array are VStorage API for Array Integration (VAAI) enabled

在EMC 最佳实践文档中要求启用VAAI以确保升级的顺利进行。

 

那么,VAAI是到底什么什么功能哪。

 

VAAI自ESXI/ESX4.1引入,提供硬件加速的功能。并不是所有存储都支持这项功能,但是XtremIO对这项功能进行了整合。如果想要XtremIO达到最优性能,就必须要启用VAAI。

 

下面我们就来看看如何启用VAAI。

 

第一步:选择“配置”

 

第二步:选择“软件”中的“高级设置”

 

第三步:选择“DataMover”,查看

DataMover.HardwareAcceleratedMove
DataMover.HardwareAcceleratedInit

1代表启用,0代表未启用

 

 

第四步:选择“VMFS3”,查看

VMFS3.HardwareAcceleratedLocking

1代表启用,0代表未启用

 

必须确保以上三项检查全都启用,即设置为“1”。

另外我们还可以通过命令行对其进行检查。

 

第一步:通过putty或者SecureCRT登录

 

第二步:分别运行以下三条命令

esxcli system settings advanced list -o /DataMover/HardwareAcceleratedMove
esxcli system settings advanced list -o /DataMover/HardwareAcceleratedInit
esxcli system settings advanced list -o /VMFS3/HardwareAcceleratedLocking

如果“Int Value" 为"1", 则表示启用

好了,关于VAAI的分享就到这里。

 

昨天有人@老司机,问老司机说自己腿长咋不上天哪。

今天老司机告诉你,学会了VAAI,上天都不算是事儿。

VAAI可以快的让你飞起来。

 

本文分享自XtremIO微信公众号

有一些人,你可能与他朝夕相对,但是你却从未真正了解他。

 

喜欢EMC是因为这里有着形形色色的人,来自于不同的国家,不同的行业,有着不同的背景,每个人都有自己的特点。如果你善于发现,每天都会有新鲜的故事。

 

今天又有和CE的故事可以讲,而且要比上期精彩多了。时间约在了晚上12点,地点是在锦江酒店,此情此景能做的事情实在不多啊,小编再清纯也要wu一次啦。

 

在故事开始之前,我们先来简单了解一下今天的主人公冰冰,他短短的却并未结束的传奇的一生足足可以写成两本大部头。

 

冰冰2006年大学毕业,拒绝了国内某知名互联网公司的offer。毅然决然地去了马来西亚留学,攻读MBA。在校期间,服务于马来西亚旅游局。而后进入马来西亚蓝海战略区域研究所担任研究员。学成归来之后,将自己的兴趣变为现实,下海经商,从事赛车配件贸易。再后来,为追寻真爱放弃事业,来到上海。如今加入EMC已将近两年,期间作为资深工程师被挑选参加XtremIO未对外公开的项目,成绩斐然。

 

好了,说回正题,今天看到冰冰明显憔悴了很多,下面就让他来亲述一下和CE的那一晚。

 

 


终于等到第二次去现场为客户升XtremIO的机会了,和蜥蜴(CE-现场工程师)约的时间提前到了晚上10点钟。心情有点小紧张。白天在办公室处理升级的同时,我也着手忙着准备各种资料。毕竟RPS日常的升级,都是通过远程完成,我们身边有大把资料可以利用,遇到问题还可以询问Senior的同事。但是到客户现场,就增加了许多不确定因素,要是遇到了问题,更多的就只能靠自己了。为此我把能想到的文档资料都整理好,并打印出来,以防万一。说来也巧,我叫徐鑫,同去的 CE叫金鑫,所以我们给这次的升级任务起了个名字—“鑫鑫相印”。


到了客户现场后,和客户稍微寒暄了一下,就着手开始升级了。客户当前的版本是4.0.1,1个X-Brick,要升到的版本是target code 4.0.2-80。在和客户确认了相关信息,回答了客户的问题后,我们就按着流程开始了升级。借着等待升级运行的时间,我和金工开始聊天,从而知道EMC的现场工程师原来也是要同时支持多个产品的,而且有时候他们一天最多要跑3-4个不同的客户,而且都位于上海的不同方位。金工在聊天中透露,他已经连续6个晚上都没回家吃过饭了,这让我深刻体会到做为现场工程师不容易。在升级过程中,客户会不时地询问我们升级到哪个步骤,是否有什么影响,我们都会一一给客户解答。

 

第一个SC(X1-SC2) 开始重启的时候,客户办公室立马就接到其他部门的电话,报告应用的性能下降了。在现场你能第一时间感受到,升级中的每一个变化对客户环境的影响,这是远程升级体会不到的。所以作为工程师的我们,肩上的责任是重大的!对于每一个细节,工程师都应当仔细查看,认真对待!因为升级中任何一个微小的变化,都有可能对客户的环境起到很大的变化。

 

升级终于在23点40分左右结束了,整体来说还算顺利。出了大楼,和金工依依不舍的挥手告别。分手了之后,走在空旷的马路上,感受着上海夜晚的丝丝凉意,心里却是暖暖的,或许这就是“鑫鑫相印”。

 

 

本篇文章是由XtremIO微信公众号特别提供。

RPS作为服务客户的一线团队,一直致力于为客户提供最佳的服务体验,也获得了国内外客户和协同部门的多方好评。在取得一些成绩的同时,我们也在努力对流程不断地进行优化。

 

基于大量的历史数据和分析,经过反复的讨论和验证,新的E2E 流程即将正式发布,今天我们就来看一看新的流程有哪些好处,又会给我们带来哪些改变。

 

 

 

新的E2E流程旨在对流程进行精简,对服务请求减少不必要的资源浪费,有效减少升级计划落地的时间。预计,采用新的流程之后,会减少80%因部门间协同所产生的问题,会降低50%与客户的反复沟通所产生的效率低下,同时对系统和资源的使用率会瘦身60%。

 

经过严格的调研和大量的数据,大约80%的请求均可遵循标准化升级计划。传统升级计划按照 “预约时间-健康检查-商讨计划-预约时间-实施升级”。现在,RPS通过预设升级计划,遵循”预设升级计划-健康检查-实施升级“,从而快速帮助客户推进升级计划,避免了因部门间协同不足所产生的计划迟滞,从而影响客户的体验。


 

 

在对流程进行变更时,对于客户需求的考量无疑是RPS放在首位的,一切的优化都是为了使客户能得到更好的服务,创立行业新的标杆。在新的流程下,会有来自于Upgrade Consultant Team的资深专家全程跟踪处理客户的升级计划。

 

客户将会有更多的机会与资深专家对升级计划来进行沟通,对日常使用中的问题进行释疑,而不仅仅局限于待升级的产品本身,诸如应用环境,工作负载等等也会纳入考量。针对特殊情况,专家将采取为客户量身定制的解决方案以满足升级计划的顺利实施,通过更好地来满足客户的需求,真正的做到End to End。

 

 

 

 

 

 

值得一提的是,RPS这次会从资深工程师中抽调精锐,组成Upgrade Consultant Team,全程负责升级计划的实施,包括但不限于完成预检,与客户讨论升级计划,以及升级计划的推进。这些工程师资历颇深, 同时支持多个产品,而且十分熟悉产品特性,能够在制定升级计划时充分考虑客户的要求及实际情况,从而做出最完善的规划。这些工程师都是RPS的宝贵财富,可谓是 Best of the Best,相信他们绝对会力争把RPS最好的一面展现给客户。

 

本篇文章摘自EMC XtremIO社区

我, 是XtremIO & Isilon GEO Lead -- Charles,同事们也会亲切的称呼我“袁老湿”。

 

(以下为本人亲述,小编代笔。)

 

如果说RPS是防患于未然的堤坝,那么Reactive Team就是堤坝出现漏洞之后的快速反应部队,总是能出现在最需要他们的地方。

 

这次很荣幸有机会在我们XtremIO Reactive Team轮岗,与Support Engineer共同经历难忘的一周里,学习到了很多知识,也看到了这些远程工程师最真实的一面。

 

XtremIO Reactive Team成立至今已经超过三年,成立之初从各个team抽调精英,由最初的4个人渐渐壮大,如今已经有20多位技术工程师,为XtremIO保驾护航。

 

第一天来到Reactive Team, Manager就贴心的为我安排了一位mentor,带我熟悉整的流程和日常工作。亚太区Reactive Team的服务时间为早上6点至下午2点,团队男女比例基本控制在1:1,正所谓男女搭配,干活不累。

 

按照计划,这几天我将主要负责响应一些来自兄弟部门包括RPS的服务请求,这样既能更好的融入Reactive Team的生活,也能更好的提高自己的技术。

 

 

其实,我们RPS平时也经常与Reactive Team打交道,向他们咨询一些专业的技术问题和解决方案。然而,只有当真正体验到了他们的工作,才知道他们他们另外的一面。一些兄弟部门的服务请求来得很突然,又需要在非常短的时间内作出响应以及进行初步的故障排查。这就要求我们的工程师有很强的multi-task的能力,往往要同时处理几个case。与此同时,可能还要承受来自各方的压力,客户总是希望问题能在最短的时间内得到最圆满的解决,而不经过缜密的排查就无法做出精确的判断,有少部分客户的不理解和催促也是可以想见的。这些能力只有在长期的工作中慢慢地积累,除此之外,别无他法。

 

在遇到一些疑难问题的时候,往往需要几位专家一起会诊,从而发现根源,解决问题。在这次轮值期间,也遇到了一些比较棘手的问题,在得到提高的同时,也深深得为Reactive Team同事们的专业知识所折服。

 

 

由于工作性质的原因,技术支持工程师都是跟着case走,很少能准时吃饭。午饭的时候经常分成两波,分别cover对方的case,吃饭也是速战速决。如果实在忙的支不开身,就把外卖拿到工位上解决,边工作边吃,一个午饭吃到下班也是经常有的事。

 

经过一个礼拜的轮岗,确实学习到了很多专业的知识,也有了自己的一些想法。最大的收获就是发现了一些RPS和Reactive Team之间的流程值得优化的地方,这也是这次轮岗的目的。

 

这次轮岗,可谓收获颇丰,也进一步认识到了我们可爱的Reactive Team的同事。在为客户圆满的解决一个又一个问题的背后,是他们所坚持的专业精神,只有融入了他们,才能深有体会。他们可能付出了很多,但是为了给客户提供最专业的服务,树立EMC的形象,无怨无悔。

 

作为两个部门之间的使者,衷心希望两个部门在今后的工作中齐心协力,为客户提供更好的服务,也深深的怀念那些陪我度过难忘一周的同事们。

作为中国网民,我们享有学习网络知识的天然优势,这是很多老外一辈子都不敢奢望的。还记得刚学会上网的时候,某知名搜索网站突然就连不上了,有位学长说这是域名被封,直接连IP就可以了,还帮我修改了hosts文件。于是我沿着这个方向研究,很快就理解了DNS协议。在实践中学到的本领,比捧着课本背诵的不知道高到哪里去。

又过了一阵,竟然连IP都连不上了。我在探索过程中,又学会了HTTP代理和VPN等科学上网技术。就这样,十几年下来身经百战,不知不觉中掌握了很多网络技术,每天都能到外网和同行们谈笑风生。现在回忆起来,我的知识真没多少是刻意去学的,而是在和网络问题斗争时被动学会的。被虐久了还得了斯德哥尔摩综合症,去年到国外出差了一个月,便觉得食不知味,因为根本找不到学习的机会。回到国内赶紧打开浏览器,Duang~~立即弹出运营商推送的广告。还是那个熟悉的味道,回家的温馨顿时涌上心头。

本文要讲述的也是一个颇有中国特色的网络技术,其实很多人都遇到过,但没有去深究。最早向我反馈的是一位细心的网友,他在打开www.17g.com这个游戏网站时,有一定概率会加载出其他网站的游戏,比如xunlei的。他觉得很好奇,便采取了一些措施来排查。

1一开始怀疑是电脑中毒,于是在同网络下的其他电脑上测试,症状还是一样。

2其他地区的网友(包括我)打开这个网站时没有发现相同问题。

3他怀疑是当地运营商(哪家运营商我就不说了)搞的鬼,于是换了个宽带,果然就没问题了。

这位网友很生气,想知道运营商究竟对他的网络做了什么手脚,所以抓了个出问题时的包来找我。我刚开始以为很简单,肯定是运营商的DNS劫持,即故意在收到DNS查询时回应一个假的IP地址,从而导致客户端加载错误的广告页面。于是我打开网络包,用dns作了过滤,发现www.17g.com被解析到了IP地址123.125.29.243(它还有一个别名叫w3.dpool.sina.com.cn,见图1)。可是经过进一步测试验证,发现这个IP地址竟然是对的,并没有被劫持。

图1.png

1

 

既然不是DNS劫持,那又是什么原因导致的呢?可惜这位网友抓包的时候电脑上开了太多应用,所以干扰包很多,无法采用暴力方式来分析(就是指不过滤,用肉眼把所有包都一一看过的分析方式)。如果用“ip.addr eq 123.125.29.243”过滤则得到图2的结果,似乎平淡无奇,只是显示有些包乱序了,但不知道这意味着什么。后来我才知道这就是线索之一,具体原因后面会讲到。

图2.png

2

 

由于这是我第一次分析劫持包,所以不得要领,当晚分析到凌晨都没有弄明白。第二天早上只好到技术群求援了,一位在运营商工作的朋友给我科普了HTTP劫持的几种方式。其中有一种引起了我的注意,其大概工作方式如图3所示,实线箭头表示正常的网络包,虚线箭头表示运营商做的手脚。

图3.png

3

 

注意:这只是简单的示意图,不完全等同于真实过程。

在正常情况下,用户发出的HTTP请求(即图中的①)经过层层路由才能到达真实的Web服务器,然后真实的HTTP响应(即图中的③)又经过层层路由才能回到用户端。而在做了手脚的网络中,运营商可以在路由器上复制HTTP请求,再交给假的Web服务器。然后赶在真实的HTTP响应之前,把假的HTTP响应(即图中的②)送达用户。这个抢先应答会导致用户在收到真实的HTTP响应时,以为是无效包而丢弃。

根据这个工作原理,我们能否推测出假的HTTP响应有什么特征呢?如果能,那就能据此过滤出关键包了。我首先考虑到的是网络层的特征:因为假Web服务器是抢先应答的,所以它发出的包到达用户时,TTLTime to Live可能和真实的包不一样。那要怎么知道真实的TTL应该是多少呢?考虑到3次握手发生在HTTP劫持之前,所以我们可以假定参与3次握手的那台服务器是真的,从图4可见其TTL54

图4.png

4

 

接下来就要动手过滤出假的包了。根据其源地址同样为123.125.29.243,但TTL不等于54的特征,我用“(ip.srceq 123.125.29.243) && !(ip.ttl == 54)”过滤,得到图5的两个包,即8号包和9号包。看看右下角显示了什么信息?这不正是我要寻找的假页面“src=http://jump.niu.xunlei.com:8080/6zma2a”吗?

图5.png

5

 

这个发现令我信心大增,有种拨云见日的感觉。再往下看几个包,果然发现了和jump.niu.xunlei.com的新连接。接着这个连接又把页面跳转到了“http://niu.xunlei.com/actives/welcome1426……”上(见图6)。跳来跳去地非常难以追寻。

图6.png

6

 

再后面的包就没必要分析了,以上证据已经足以向工信部投诉。据说投诉后运营商解决起问题来还挺爽快的,百度曾经上诉某运营商的劫持案件也获赔了。商场上的黑暗故事,就不在本书里展开讨论了,我们还是继续关注技术问题吧。

在这个案例中,万一真假网络包的TTL恰好一样,还有什么办法可以找出假的包吗?仔细想想还是有的。比如服务器每发送一个包,就会对其网络层的Identification作加1递增。由于4号包的Identification4078(见图7),那它的下一个包,也就是8号包的Identification就大概是4079了(或者略大一些)。可是从图8可见,它的Identification一下子跳到了55872,这也是一个被劫持的明显的特征。

图7.png

7

 

图8.png

8

 

那万一运营商技术高超,把TTLIdentification都给对上号了,我们还有什么特征可以找吗?还是有的!刚刚介绍的两个特征都在网络层,接下来我们可以到TCP层找找。在图5可以看到8号和9号这两个假冒的包都声明了“win=2102400”,表示服务器的接收窗口是2102400字节。对比一下其他网络包,你会发现这个数字大得出奇。为什么会这样呢?这是因为真正的Web服务器在和客户端建立3次握手时,约好了它所声明的接收窗口要乘以128(见图9)才是真正的窗口大小。假的那台服务器不知道这个约定,所以直接把真正的窗口值(win=16425)发出来,被这么一乘就变成了16425×128=2102400字节,大得夸张。

图9.png

9

 

这个特征在本案例中非常明显,但不是每个TCP连接被劫持后都会表现出来的。假如3次握手时没有声明图9所示的Window Scale值,那就无此特征了。

其实我在一开始还提到了另一个现象,即图2Wireshark提示的[TCP Previous segment not captured]和[TCP Out-of-Order],意味着存在乱序。为什么会有这些提示呢?这是因为假服务器伪造的包抢先到达,增加了Seq号,因此等到真服务器发出的包到达时,Seq号已经对不上了。Wireshark还没有智能到能判断真假包的程度,只能根据Seq号的大小提示乱序了。

总而言之,在理解了劫持原理之后,我们便能推理出假包的特征,然后再根据这些特征过滤出关键包。但不是所有特征都能在每次劫持中体现出来的,比如接收窗口的大小就很可能是正常的,所以一定要逐层认真分析。这还只是众多劫持方式中的一种,如果采用了其他方式,那么在包里看到的现象又会有所不同。等我下次遇到了,再写一篇跟大家分享。


作者信息:

林沛满

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

 

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

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

NetWorker有一个非常重要的参数,就是索引。这个参数对于备份和恢复都起到很大的作用。客户基本都知道索引的概念,但是如何有效地管理索引,如何更好的利用索引,却很多客户不太清楚具体的流程和操作。这里就和大家简单的介绍一下索引。

 

索引在生活和工作的很多方面都存在,每个人都应该对索引感到不陌生。我们的图书馆系统就有庞大的索引系统。您需要借阅一本图书,可以在电脑里面简单的根据书名,作者或者其它信息搜索,搜索结果告诉您图书的数量,具体的存书位置,是否可以借阅,如果借出什么时候可以归还等等。所有借阅者可以简单的通过网络来了解图书馆庞大的藏书系统。

 

NetWorker的索引客户基本上无法接触,客户端文件索引是NetWorker服务器的控制文件数据库之一,其它两个是resmm,这些数据库跟踪客户端备份的每个文件(路径名),从而允许用户浏览特定时间点的文件备份。NetWorker服务器在每个物理客户端上创建并且维护一个CFI.

 

客户端的文件索引存储由备份客户端生成的有关客户端的备份文件和目录的信息。对于备份的每个文件和目录,CFI将包含其路径名,文件属性(如权限和所有权)以及表明何时备份包含该文件的存储集的时间戳,NetWorker的客户端将跟踪信息发送至各自的CFI,后者驻留在NetWorker服务器上。每台物理客户端有一个CFI

 

经常会有用户突然发现自己的磁盘空间突然满了,源头就是索引文件夹过大。这个时候往往客户就会有疑问:为什么一个索引文件夹可以达到几十个G?这往往有两个可能性:

1. 客户设置的浏览策略过长。这个浏览策略决定了文件在CFI里面的保留时间。这个浏览策略的设置如下:

4271.png

2. 存储集的文件系统过于复杂。如果碎文件过多,也会影响索引的大小。

 

对于索引文件过大,这个问题怎么解决呢?对于这个问题,我们的解决方案有很多种。下面给大家简单介绍一下各种方法的实用性。

1. 可以通过命令行来修改浏览时间。这个命令的格式如下:

4272.png

2. 可以在NMC -> Media下面去删除索引:

4273.png

3. 我们还有一个解决方案。就是可以把索引文件夹整体迁移到其它硬盘下面。这个操作可以在客户端属性下面配置:

4274.png

 

通过及时地管理和维护索引信息,我们既可以有效地实现定时恢复,也不会造成备份环境的故障。这样才能高效的管理我们复杂的备份环境。

 

Mandy Xu

NetWorker技术支持工程师

Data Protection and Availability Solution

EMC客户服务

Filter Blog

By date:
By tag: