排除实际的 AIX 故障

基本过程

当系统情况不符合预期时,应该做什么?当服务器看起来不正常时,如何在 AIX 中解决这些棘手的问题?在本文中,学习在日常实际情况下排除故障的基本技能。

Christian Pruett, 技术支持工程师, 自由职业者

Christian Pruett 是一个 IBM 全球服务团队的 p 系列主机工程师。他毕业于科罗拉多州立大学的历史系,拥有学士学位。他拥有 IBM 认证管理员认证,职业经历主要是围绕 RS/6000 主机,p 系列主机硬件和系统的支持工作。他目前是 IBM IGS 的一名团队负责人。



2011 年 5 月 17 日

许多人可能还记得上世纪 80 年代在周一晚上的橄榄球节目 “You Make The Call” 中播放的 IBM 广告。这个节目会展示赛场上发生的有趣情况。主持人解释球员做了什么,特别指出其中可能犯规的地方,然后问观众他们会怎么裁决,请观众打电话回答。播放 IBM 产品或服务的广告短片之后,主持人回来,总结裁判员做出的裁决和采用的规则。这是了解美式橄榄球的好方法,经常成为餐桌上的话题。

常用缩写词

  • LPAR:逻辑分区
  • SAN:存储区域网

在本文中,按相似的方式学习如何解决 IBM AIX® 中的实际问题。您会了解相关的工具和知识,从而提升解决可能会遇到的一些棘手问题的技能。本文给出我曾经遇到的两个有意思的场景,提供探测异常情况的步骤。然后停一下,让您推测什么出了问题,最后给出答案。

示例问题

首先描述我作为系统管理员遇到的两个问题。

问题 1:服务器更大,而计算能力却降低了

当时,我需要把一个 AIX 5.3 LPAR 从基于 POWER4™ 的老式 IBM pSeries® p670 服务器迁移到基于 POWER6® 的全新的 pSeries p570 服务器上。老的服务器资源不足(使用 Workload Manager 管理服务器上主要应用程序的资源),因此新硬件上新的动态处理器资源应该会提供我需要的计算能力。我对这个 LPAR 执行了 mksysb,然后使用 Network Installation Manager 在新硬件上恢复它并通过 SAN 磁盘映射它。

我启动了这个 LPAR,直到启动应用程序之前看起来一切顺利。突然之间,用户开始打电话来了。他们根本无法访问自己的产品了。当我登录时,发现服务器完全是空闲的。服务器上根本没有消耗资源很多的进程。用户为什么会遇到问题?

问题 2:出故障的硬盘无法解除镜像

我的一台服务器具有镜像的 root 磁盘。有一天,错误报告指出在其中一个磁盘上坏块无法重新定位。我知道这是硬件故障的先兆,所以开始解除镜像。但是,服务器说无法完全解除镜像,因为其中一个逻辑卷只有一个好拷贝,它就在出故障的磁盘上。我应该怎么解决这个问题并更换硬件?


故障排除过程

记住这两个示例问题,现在看看解决它们的过程。

步骤 1:别乱动

一旦发现有麻烦了,最明智的举动就是别乱动。就像印地安纳·琼斯在 “夺宝奇兵” 中一样,如果发现踩上地板就会有飞镖射向您,那么就停在原地,不要继续前进了。更多的变动只会让问题复杂化,可能把情况弄得更糟。当一个问题影响系统正常运行时,不得不解决多个问题是没有意义的。

对于 第一个示例问题,我让用户马上退出系统,然后我终止应用程序。我知道在性能很差时用户的查询和输入会中断,这可能会破坏他们的数据,在我检查系统之前不希望他们的环境有进一步的变动。尽管用户不愿意听到他们现在不能使用新的服务器,但是知道我正在查找问题的原因,他们会很高兴。另外,这让我有时间按自己的方式执行其他故障排除步骤。

步骤 2:先从基本命令开始,然后增加复杂性

在我学功夫时,听到了一位二级黑带在公共汽车站制伏小偷的故事。同学们都想知道她用哪一招放倒了进攻者。是金虎式吗?还是八卦掌中的圈掌?我们甚至想像她非常厉害,用醉八仙把对方放倒了。结果都不是:她使用的是白带在班上最初学习的技术之一 — 肘击前胸,再拳击鼻子。

AIX 提供了用于检查服务器的各个方面的命令,包括硬件和软件。即使是最基本的命令也会为分析问题提供很好的基础。当信息不够或仍然有些东西表现不正常时,可以开始尝试更复杂、更强大的工具。但是,应该从最简单的命令和想法开始,然后再使用更强大的工具。

例如,AIX errpt 是在各种风格的 UNIX® 中都能够找到的基本工具之一。它提供关于硬件和软件问题的各种信息。如果使用 –a 标志或 –j 选项和标识码,会产生更详细的输出,输出描述问题的类型、受影响的组件以及系统如何根据错误的类型做出反应。如果它提供的信息不够,可以用 diag 命令进一步检查系统,这个命令会在硬件和操作系统的各个部分上运行测试。

对于 第二个示例问题,我先通过查看 errpt 输出寻找硬件问题,然后使用 unmirrorvg 命令 — 尝试解除镜像的简单但强大的工具 — 而不是对磁盘上的每个逻辑卷运行 rmlvcopy。当我发现有一个逻辑卷无法删除时,就使用 lspvlsvgmigratepv 等其他基本命令收集信息。我尝试用 extendvgmirrorvg 在另一个磁盘上创建卷组的另一个拷贝。这仍然留下了一些旧的分区,所以我更进一步,用 syncvgsynclvdom 协调 Object Data Manager 与服务器。最后,我用 migratelp 尝试把各个逻辑分区转移出这个磁盘。不幸的是,这些工具都不奏效,但是它们提供了大量信息。

步骤 3:再现问题

按照科学的方法,任何假想和试验的关键一点是,能够重建过程并产生相同的结果。如果做不到,结论至少是不确定的。在最糟糕的情况下,这会颠覆科学家的理论并损害他们的名誉,就像在上世纪 90 年代宣称实现了室温冷聚变的物理学家一样。

或者,按我的说法:如果一开始不成功,那么在其他地方试试是否可以造成同样的问题。

在管理 AIX 服务器时,如果某些东西出了问题,而您有再现问题所需的资源,那么在另一个相似类型的 LPAR 上执行相同的操作,看看是否会产生相同的结果。如果在另一个服务器上修改相同的属性会造成相同的结果,就可以推论这个操作就是问题的根源。但是,如果产生了完全相反的结果,那么要研究服务器之间的细微差别,尝试推测造成问题的原因。

对于第一个示例问题涉及的 LPAR,我发现当把 SAN 磁盘交换回老的 p670 服务器并启动它时,问题没有出现。用户能够访问他们的应用程序,CPU 承受正常的负载,CPU 利用率为 80% 多(10% 内核 + 70% 用户)。因此,我能够断定是 p570 服务器上特有的某些东西导致了问题,而不是迁移过程中引入的某些东西。

步骤 4:研究问题

在信息时代,只需敲几下键盘,点几次鼠标,就能够获得大量信息。更好的是,系统管理员往往是大型社区的成员,社区记录了很多人多年的经验。

首先应该查阅生产商和销售商自己的资料。IBM 这样的公司在网上公开他们的所有手册、Redbook、技术文件甚至 man 页面以供研究。只需在主站点的搜索栏中输入简单的关键字,就可以找到大量可能有帮助的建议和信息。

我推荐的其他信息源包括其他系统管理员经常访问的各个新闻组、论坛和站点。成天与服务器打交道的人往往会经常访问技术站点,并对在工作过程中看到的东西发表评论。对于公开的求助,大多数系统管理员乐于提供指点,或通过电子邮件往来提供帮助。另外,常常可以找到与操作系统和软件的其他版本相关的旧信息,可以通过它们找到更多信息。

对于这些信息源,主要的使用技巧是使用适当的关键字集。如果我使用 Google 这样一般性的网站研究 AIX 问题,那么会确保搜索字符串以 AIX 开头,以便排除与其他风格的 UNIX 相关的信息。然后,可能会包含命令的输出或 errpt 产生的标签等内容。我还会确保在特定的短语前后加上双引号 (""),以便把搜索限制在这些特定的问题,避免无关的信息,对于常用的单词(比如 Logical Volume Manager)尤其应该这么做。

对于磁盘坏块重定位失败的问题,在 Google 上使用短语 AIX "bad block relocation" failure 进行搜索产生了几百个结果,但是看起来没有与我的情况相符的。

步骤 5:取消所有更改

有时候,解决问题最明智的做法是取消已经做的所有更改,回到原来的状态。这个步骤并非总是可行的。有时候,过分热心的 C 级执行官强迫您回退他们的服务器。或者,由于时间紧迫,有必要这么做。无论如何,回退是可供选择的最好的战术之一。

我把这个步骤放在故障排除步骤列表的中间位置,这是因为有时候必须早点儿这么做,有时候要晚一些。但是根据我的经验,我觉得最好先完成前四个步骤,然后再考虑取消所有更改。如果在故障排除过程开始时马上取消更改,问题很可能没有解决,下一次尝试相同的工作时还会遇到相同的麻烦。如果在过程中过晚回退,会影响正常运行时间,或者让问题复杂化,到了不可能回退的程度。

对于第一个示例,由于时间的原因,我实际上不得不回退了服务器迁移操作。如果这个生产服务器停运更长时间,用户和公司就会损失金钱。重新安排这项工作花了一周时间,这让我能够多做一些研究,但是当我再次尝试迁移时,问题又出现了。对于第二个示例,无法对硬件问题执行回退。无法告诉服务器,“回到发生坏块重定位错误之前的状态!” 我不得不继续努力克服磁盘的故障。

步骤 6:每次只更改一处规则

如果上面的所有步骤都不奏效,您决定开始更改主要组件或者对服务器做更激进的操作,那么要记住一条最重要的规则:每次只更改一处。

多处更改会导致两种情况之一。首先,如果这些更改解决了问题,那么您不知道哪个更改是有效的操作。如果您不关心究竟是什么解决了问题,这可能没什么大不了的,但是出色的系统管理员都希望掌握更多知识,因为他们知道问题往往会在同一地方多次出现。第二,如果问题没有解决,这可能会引入更多复杂性。继续这样做,您会不知道要取消哪个更改。如果走得足够远,系统会乱成一锅粥而您被弄得一头雾水。(xkcd 上有一个关于这种情况的笑话。)

如果做一处更改之后问题没有解决,通常希望取消它并尝试其他措施。在第一个示例中就是这种情况:当我对比两个服务器的 Hardware Management Console 概要文件时,看到它们不一样。我注意到老的 POWER4 硬件使用专用的 CPU,而新的 POWER6 硬件使用不封顶的共享 CPU 池。我想知道这一差异如何影响 CPU 性能,所以修改了 POWER6 硬件上的概要文件以使用专用的 CPU。奇怪的是,根据用户的反馈,服务器 “正常” 了,我在处理器上看到了负载。因此,我知道问题肯定与 CPU 资源有关,但是需要查明为什么会这样。

步骤 7:求助于 IBM Support

如果已经尝试了所有合理的步骤,需要新的想法,通常应该联系 IBM Support。他们有高级的故障排除工具,有精通操作系统和相关产品(比如 VIO 和 PowerHA)的每个方面的专家,可以调出相关的案例以证实并协助解决相似的问题。但是,如果您以前没有拨打过 800-IBM-SERV,有几点需要了解。

首先,您应该有 IBM 合同号。有多个支持级别,从最高级的由专人负责的 24x7x365 支持直到适用于非关键服务器的上午 8 点到下午 5 点支持。可以直接从 IBM 购买这些支持服务包,也可以与增值销售商签订合同。

还需要提供一些信息,让 IBM Support 可以调出您的账户 — 通常是服务器所在地的电话号码、序列号、合同号或物理位置。这一信息很大程度上取决于您建立的是硬件案例还是软件案例。

还必须让支持人员了解问题的严重程度或优先级。优先级分为从 1 到 4 几个级别。1 级通常涉及系统停止运行或生产影响,对于这个级别会马上把电话转给技术人员。4 级意味着处理时间可以长一些,通常用于一般的管理问题。

您描述问题并建立支持案例之后,会给您一个跟踪号 — 通常称为 PMR。这个号码向与您协作的其他支持人员标识这个案例。硬件和软件 PMR 是惟一的,如果您的问题跨越边界,就需要得到新的号码。

对于两个示例问题,我都不得不联系 IBM。对于第一个问题,IBM 调动从 VIO 支持到内核团队的多方面人员参与解决问题。对于第二个问题,只有硬件技术人员参与,我提供了来自 snap 命令的信息以供分析。

步骤 8:走极端

有时候,没有其他方法能够解决问题,只能尝试大多数人认为是发疯的某些非正统措施。当您已经绝望,甚至工作或生命岌岌可危时,通常会这么做。在这种情况下,IBM 支持人员常常会说,“如果您这么做,就会处于不受支持的状态,必须重新开始,然后我们才能够支持它。” 但是,如果您的解决方案是有效的,可能能够化险为夷。

对于我的第二个示例,在我联系 IBM Support 之后,他们说惟一的方法是生成 mksysb 映像以恢复服务器。由于我们没有更多东西可失去了,与我的管理员团队讨论之后,我们打算对 root 磁盘做三重镜像,然后从服务器上拨出磁盘。拨出磁盘可能导致服务器无法引导。但是,潜在的风险是拨出磁盘可能干扰更大的服务器,让它上面的所有 LPAR 崩溃。我们真敢这么做吗?


您来回答

既然我已经提供了问题的背景,该您来回答了。总结一下:

  • 把一个启用了 Workload Manager 的服务器迁移到更快的硬件上,但是工作不正常,除非是把 LPAR 概要文件设置为使用专用的 CPU 而不是动态 CPU。这是为什么?
  • 如何从无法撤销配置的磁盘恢复服务器,或者取出无法移出这个磁盘的物理分区中的数据?

如果您有主意了,就继续。


实际发生的情况

造成第一个问题的是 Workload Manager。使用它的应用程序被限制为只能使用 CPU 的 50%。因此,当系统管理程序轮询循环探测到那个 LPAR 时,它问 “您需要多少 CPU?” 服务器回复,“我目前只使用分配的 CPU 的一半儿。” 因此,系统管理程序会动态地把 CPU 标称值减少一半儿。这个循环重复几次之后,CPU 计算能力多次减半,基本上接近零了。为了解决这个问题,把 Workload Manager 池调整为最多使用 CPU 的 100%,这样动态的 CPU 标称值会适当地限制其本身。

对于第二个示例,最终只能执行备份和恢复。对于块重定位失败,没有企业乐意采用临时解决方法。根据 IBM Support 所说,这个问题很少见,只能执行 mksysb 把数据备份到好的磁盘上并恢复系统,没有其他选择。恢复操作系统之后,就可以以安全的方式热交换坏磁盘并更换它,而不会危及硬件上的其他 LPAR。


结束语

希望您对系统管理员如何排除 AIX 服务器的故障、可以使用的战略、应该避免的做法以及在哪里寻找解决问题的建议有了一些认识。这些步骤并不完全适合所有情况,还有其他选择,但是这些步骤可以指出正确的方向。

参考资料

学习

  • AIX and UNIX 专区:developerWorks 的“AIX and UNIX 专区”提供了大量与 AIX 系统管理的所有方面相关的信息,您可以利用它们来扩展自己的 UNIX 技能。
  • AIX and UNIX 新手入门:访问“AIX and UNIX 新手入门”页面可了解更多关于 AIX 和 UNIX 的内容。
  • AIX and UNIX 专题汇总:AIX and UNIX 专区已经为您推出了很多的技术专题,为您总结了很多热门的知识点。我们在后面还会继续推出很多相关的热门专题给您,为了方便您的访问,我们在这里为您把本专区的所有专题进行汇总,让您更方便的找到您需要的内容。
  • AIX and UNIX 下载中心:在这里你可以下载到可以运行在 AIX 或者是 UNIX 系统上的 IBM 服务器软件以及工具,让您可以提前免费试用他们的强大功能。
  • IBM Systems Magazine for AIX 中文版:本杂志的内容更加关注于趋势和企业级架构应用方面的内容,同时对于新兴的技术、产品、应用方式等也有很深入的探讨。IBM Systems Magazine 的内容都是由十分资深的业内人士撰写的,包括 IBM 的合作伙伴、IBM 的主机工程师以及高级管理人员。所以,从这些内容中,您可以了解到更高层次的应用理念,让您在选择和应用 IBM 系统时有一个更好的认识。
  • 技术书店:阅读关于这些和其他技术主题的图书。

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=AIX and UNIX
ArticleID=659784
ArticleTitle=排除实际的 AIX 故障
publish-date=05172011