|
|
征文：我和EMC CX700不得不说的故事我的存储故事不象某些企业恢复多少多少数据那么紧张，因为那明显就是管理与规划的问题。作为国内规模较大的系统应用平台之一，在我这里不可能发生这样的故事，一旦发生我也就不必在这里呆着了。对于存储系统而言，数据丢失后如何补救是下下之策，重要的是先期做好规划，做好备份，预防故障的发生。 我的第一个存储故事直接定位在了一个很小的故障解决上，虽然事情不大，但是拖了我很长时间，也最终直接导致了我对EMC CX系列操作的非常熟练，包括上架、连接、升级存储的软件版本、改变任何配置等等操作。我的第二个故事则是关于双机系统扩充光纤卡的问题，个人感觉比第一个更具普遍意义，因为在需要提升性能和可靠性的时候，给主机扩充一块光纤卡是较为常见和管用的手段。 前言：初入存储江湖 在早先的时候，公司的后台系统曾经大量使用过EMC的CX系列。不过这些设备都是从DELL那里买进的，也叫Dell EMC。 那是一个什么样的时代啊，我们作为系统管理员，基本上对SAN与存储是一无所知，而Dell呢，服务是好的，技术是一般的。所以，基本的系统上线、升级等等工作的调试都变得艰巨异常。第一个来给我们安装配置SAN的DELL工程师，据说因为3天都没有配置成功，回去被fire掉了。嗬嗬，这是题外话，暂且不提。 正式开始重视存储系统，还是在一次事故以后，有几台SAN环境中的机器需要搬迁。搬迁之前我们也战战兢兢担心出错，于是要求厂商把所有的光纤线都做了标记，但是，担心的事情还是发生了，可能是标记出了问题，真正再插入光纤线的时候，认不到原来的硬盘了。 痛定思痛，我们决定不再依赖厂商，自己掌握z主动权学习存储技术。于是从一无所知，到现在能在SAN，存储产品上了解这么多的东西，很多都是自己经验的积累。下面我就讲两个我的工作经历中与CX700相关的小故事，第一个是CX700软件版本与powerpath软件之间的小故事。 与Powerpath4.5的第一次亲密接触 众所周知powerpath是EMC CX700常用的配套软件之一，问题的起因是我们安装了一台CX700的存储到一个新的AIX主机上，DELL的工程师直接在主机上安装了当时最新的powerpath版本，PP4.5。这个据说是一个比较稳定的版本，而之前我们用的都是PP4.2，我对新的软件还真是满怀期待。当一切都做好之后，我开始测试存储的速度了，却发现一个问题，存储的写速度怎么也上不去，最多每秒只有60M左右。 这个速度可绝对不是CX700应有的表现，一定是什么地方出错了。 于是我们开始查找问题，最初的时候，怎么也没有怀疑到powerpath上，我们检查了存储，光纤连接，光纤交换机……然后检查主机上的软件配置，光纤卡的参数……整个系统差不多都被我们翻得底朝天了，也没有发现任何问题。 最后，我们甚至重新安装了powerpath，问题依旧存在。这个时候，已经是晚上很晚了，我们都很郁闷，但是也都只能蹲在那里抽烟，不知道怎么办好。好在现场一个DELL的销售灵光突现的说了声，会不会是powerpath的问题？我们换回老版本看看吧。于是重新安装老版本，速度正常了，问题居然就这么解决了…… 二次接触Powerpath 4.5 设备是可以正常用了，但是，我们谁都不知道是什么原因，之后与DELL方面交流过几次，基本怀疑是CX700的软件版本太老，其实就是CX700的flare operating environment，当时是2.14的版本。 直到我们要安装另外一台CX700到AIX主机上的时候，才发现问题不是那么简单。我们先做了RAID，发现软件版本是2.14，于是就升级到了当时最稳定的版本，2.19.，在主机上安装了PP4.5，结果发现问题依旧。 因为这次的时间比较充足，我决定要求DELL查找一下原因，DELL于是派了一个工程师过来。这个工程师技术一般，却有一个特长，就是能打电话，他可以不停的电话骚扰别人，从中国到新加坡，甚至到更远的澳洲。在n多人的指导下反复的安装测试，原来的问题不仅是没有解决，反而导致了另外的问题，如powerhdisk盘出现了混乱，pvid也出现了严重错误，他的电话不得不变的更多了。 我郁闷了，开始担心如果再弄下去，会出现一大堆我也解决不了的问题，于是决定结束这次检查。我先是删除干净新版本的PP，再安装回PP4.2的老版本，凭借OS的经验解决了powerhdisk与pvid的问题。问题依旧是没有解决，这样看来不是简单的软件版本的问题。 柳暗花明，得来全不费功夫 我已经习惯PP4.2了，这下决定接受现实就这么用着吧，于是很长一段时间都没再去折腾那个CX700，直到公司又采购了新的CX700。 新来的CX700软件版本买过来就是2.19的，我仍然不信邪再一次尝试安装了PP4.5，居然一切正常，这下又勾起我想解决前面的问题的欲望了。 于是，我拿这个正常的CX700与前面性能有问题的CX700反复测试，也没有发现哪里有不同，但就是在PP4.5上速度有差别。 问题的最终解决了，解决的过程我也没有想到。原来，正好有一台软件版本从2.14升级到2.19的CX700。整个重做过程中，我也重做了RAID，本着找问题的精神，我还是装了PP4.5，居然这次正常了。 晕，对照以前的做法，唯一不同的就是，以前是先做RAID，再升级软件，就不可以用PP4.5，这次是升级软件以后，再做RAID，居然就可以了。为了确定其正确性，我找了一个软件版本还是2.14的机器，先升级到2.19，连接PP4.5，就是速度有问题，但是重做RAID后，速度就正常了。 问题最终是知道怎么回事了，但是，我也是一直郁闷着过来的，这样的问题，谁能想得到呢，难道Raid跟CX700的软件也挂上关系了。我也不想调查最终原因了，如果调查，可能只能问CX700的开发人员了。 这是一个CX700与powerpath的故事，下面我该说说我在CX700上遇到的另外一个故事，这个故事或许比上一个故事更有意思，也更有借鉴意义，因为在实际工作中，大家可能会经常遇到。 老网管遇到新问题，HA主机光纤接口卡无法扩充 故事的起源就在于我们的HA的AIX主机，以前只有一块光纤卡通过一个光纤交换机连接到CX700。现在，我们找IBM再买了一块光纤卡准备安装上去，通过另外一个光纤交换机连接到CX700，把双通道路径扩展成为4通道路径。 既然是HA的机器，停机问题不大，找一个晚上，约上IBM的工程师，Dell的工程师，恩，就是我上篇说到的那个很会电话的工程师，这次他表现一样没让我们失望，我们一起去了机房。 我们的想法是感觉应该会比较容易的，标准步骤如下： 1、在IBM主机里面插上新卡 当然，有这么简单，就没有下面的故事了。 第一步与第二步都很正常，第三步，如果是先认卡再接的光纤线，主机这里需要再执行cfgmgr，其实就是给光纤交换机发一个信号，否则，光纤交换机认不到卡的WWN。这个也没有费什么时间就过了。步骤4我配置通过，步骤5，我与DELL的工程师都检查了，连接状态那里的确是4个路径，都正常了，那么，我们开始步骤6。 我们先用rmdev -dl删除了以前的阵列上认到的盘，用cfgmgr -v去认，发现只有2条路径……我们下了狠招，rmdev -Rdl fcs(x)，把整个光纤卡都删除了，重新认，还是只有2条路径……我们就开始郁闷了，于是DELL的工程师又开始打电话了…… 摆平光纤卡，又出节外生枝 我没理会DELL工程师打电话，自己开始检查整个环境： DELL的工程师电话的同时，还不忘记问IBM的工程师，“我们那里都正常，应当是你们的问题”。IBM的工程师则说，“盘都认不到，应当是你们哪里的问题”。 听着他们俩在那里纠缠，我就在想是哪里出了问题呢？其实，也就是脑袋里一闪念，突然想到会不会是CX700的store group那里有问题？正常来说，store group只是决定了哪个主机能访问哪些lun，应当不会有问题，但是，现在能与主机扯上关系的，只有他了。 立即行动，我先把主机上所有的阵列盘删除，然后把HA的主机从store group中踢了出来，确定一下，再放进去。确认，主机上重新认盘，正常了。那边DELL的工程师还在电话呢，我与IBM的工程师于是一起叫道，“兄弟，别打电话了，已经好了”。 这个问题是好了，我们又发现了一个新的问题：因为我们删除的太猛，所有主机认出来的硬盘都没有PVID以及VG信息了。 本身，这个问题在平时并不难解决，但是要知道这个是HA的机器，这些硬盘其实都是正在使用的，因此我们无法使用常规的方法获得PVID与VG信息。换句话说就是，我们不能使用正常的importvg来导入VG，也没有办法使用chdev -l hdiskpower(x) -a pv=yes的方法获得PVID与VG信息。 怎么办呢？这下好了，DELL的与IBM的工程师都去打电话了…… 硬汉就要下猛药，给RAC解锁 寻求帮助没有什么成果，那我只能来狠的了，因为HA的机器不能执行importvg的原因，就是因为主节点也正在使用这个VG，那么临时解除这个锁不就可以了。 于是我进行了如下的操作： 这里一定要提醒各位，以上的操作是具有风险性，因此本人不建议模仿操作，如因为模仿上述操作发生事故，请自负其责。要知道在并发系统，如RAC上是不能随便解锁的，就是单节点的系统，解锁操作也要小心谨慎。我之所以采用这么冒险的做法，主要是因为我们这里在晚上的业务压力小，而且本身时间短，关系就不大了。 HA终于恢复正常了。再仔细想想整个经过，其实我们也就是忽略了store group那里。我估计问题发生的原因是store group把路径信息给记录进去了（或者是缓存起来了），因为它是最终决定什么主机可以使用什么LUN的关键，问题在于store group是不应当决定路径个数的，而我们事先没想到，于是问题就出现了。而第二个问题的出现，则是因为我们急于解决第一个问题，采用了一些非常规的操作才出现的。 新网管遇到老问题，CX3-80上演同样故障 其实在这个问题上，不仅仅是DELL的工程师没有现场解决能力，在今年的CX3-80的测试上，EMC的工程师遇到同样的问题时，也一样束手无策。 这里说到CX3-80，其实就是CX700的一个乘以2的翻版，把前后带宽，cache容量，磁盘最大连接个数都翻了一倍，但是后端的环路并没有增加，所以，个人的建议是如果追求高带宽的话，是一个不错的产品，如果追求IOPS，则需要考虑一下。 在这次的测试中我们需要更换一个光纤卡，准确的说，整个环境是包括了4台主机的RAC，实际情况是每台主机都需要更换一张光纤卡。我徒弟与2个EMC的工程师就过去了，一直在机房里面鼓捣。 到下午快下班的时候，我问我徒弟进度怎么样，他们说EMC卡在那里了，已经2个小时了，我问什么原因，徒弟告诉我说新换的卡光纤路径认不到，EMC的工程师正在向总部寻求帮助。后来知道，这两个工程师是比较年轻的工程师，还没有什么经验。 我晕，同样的问题，在CX3-80上同样存在。赶紧的告诉他们，你让他们别打电话了，我知道是怎么回事。 我根据上次的经验，让他们把主机从store group中拿了出来，确认后再放进去。他们告诉我，有2台主机正常了，但是2台主机不正常。ft，老方法不管用啊！确认他们的操作也没有问题以后，我说，你们把ip给我，我登陆进去看看。 登陆到这台CX3-80，我检查了一下连接状态，这才发现他们这台CX3-80已经给N多人做过测试，连接状态里面全是乱七八糟的主机光纤卡。我又看了看那两台不正常的主机，连接状态都不对，存在一定冲突，当然改store group是没有效果了。 我先把那些乱七八糟的，以前注册进来的光纤卡全部删除，然后重新注册这两台机器的光纤卡，OK，一切正常了。为了确保没有问题，我又把store group再操作了一次，让他们在主机上重新认一下。不久，他们告诉我，都正常了…… 后记：经验总结，预防胜于补漏 两个问题到此为止也结束了，这两个问题在我的工作中都耽误了我很长的时间，让我很长一段时间内百思不得其解，而一旦知道之后，却觉得格外简单。技术就是这样子，知道的人都简单，不知道的人都复杂，而从不知道到知道的解决过程，则是一个人快速成长的路程。我也是这样，一步一步从入门到了解到精通，慢慢的了解了存储产品。 另外一个要提醒各位的就是，检查机器的时候一定要每个环节都考虑到。就是这样，你觉得最不容易出现问题地方，往往就出现了问题。 最后想说的就是，我虽然一直在企业作系统管理，但是我也看见过很多的问题企业，数据保护措施非常不到位，机房管理混乱。这样的客户不发生问题才怪，而一旦发生问题，就给自己、集成商和厂商都带来极大压力。对于存储而言，因为保存着企业至关重要的数据，因此发生事故后如何补救其实并不是最重要的，往往补救的时候为时已晚，最重要的还是先期做好规划，做好故障的预防措施。
责编：
微信扫一扫实时了解行业动态
著作权声明：kaiyun体育官方人口 文章著作权分属kaiyun体育官方人口 、网友和合作伙伴，部分非原创文章作者信息可能有所缺失，如需补充或修改请与我们联系，工作人员会在1个工作日内配合处理。
|
最新专题
|
《存储前沿趋势开讲啦》第一季 .为大数据再造存..
华赛存储培训：第三章_raid技术_v2.0.ppt|
|
