在本文中，按相似的方式学习如何解决 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。当我发现有一个逻辑卷无法删除时，就使用 lspv、lsvg 和 migratepv 等其他基本命令收集信息。我尝试用 extendvg 和 mirrorvg 在另一个磁盘上创建卷组的另一个拷贝。这仍然留下了一些旧的分区，所以我更进一步，用 syncvg 和 synclvdom 协调 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 服务器的故障、可以使用的战略、应该避免的做法以及在哪里寻找解决问题的建议有了一些认识。这些步骤并不完全适合所有情况，还有其他选择，但是这些步骤可以指出正确的方向。
原文链接：http://os.51cto.com/art/201105/264283.htm
