AIX系统rootvg硬盘更换场景汇总
AIX系统rootvg硬盘更换场景汇总
pSeries小型机日常维护过程中，经常会遇到AIX操作系统所在rootvg故障盘的情况。系统换盘对于硬件维护人员来说是极为普通的一件事，但就在这常见的换盘流程里也隐藏许多让你一时不知所措的情况。
rootvg是AIX操作系统所存在的VG，在生产环境中rootvg的硬盘都做了冗余保护措施，它可以通过硬件raid卡来实现，但绝大多数情况却是通过LVM逻辑卷镜像的方式来做保护，本文我们就主要讨论通过LVM操作逻辑卷镜像硬盘更换时所遇到的各种情况。
一、定义报错故障硬盘的两种状态。
第一种，硬盘频繁报错，lsvg &p
rootvg硬盘状态为active，但可以进行读写。
第二种，硬盘彻底损坏，lsvg &p
rootvg硬盘状态为missing或者removed。
常见的rootvg大多有两个PV组成。
rootvg中的lv通过mirrorvg
做了镜像关系。
如果硬盘出现故障，应该能看到lv
status状态变为了stale,通过lslv -m hd2 查看lv的stale的状态。
二、开始模拟场景
部分lv未镜像，在unmirrorvg后，故障硬盘上仍然存在某些lv，导致无法reducevg 这块硬盘。
这时需要查看报错硬盘上lv的状态是否正常，如果可读写，可以通过migratepv 将lv从故障盘迁移到好盘。
通过lspv确认hdisk0上有足够的free
pp，既可以执行迁移命令“”。
如果硬盘彻底损坏，就需要从系统中删除lv定义，建议直接删除文件系统，当删除文件系统的同时，对应的lv将自动被删除。如果只删除lv，文件系统的定义将依然存在于系统ODM库中和配置文件中。
删除故障盘上lv定义后，继续走更换流程，待更换完毕后再重建删除掉的lv及文件系统并恢复数据。这里可以看到平时对数据备份和lv进行镜像是非常重要的。
在unmirrorvg后发现有lv同时在两个pv上存在，即为lv跨pv的情况，这种情况和上面的处理方式一致。
1．如果故障盘还可以读写，尝试将故障盘上部分lv迁移至好的pv上。
此项操作的前提是好盘上存在足够的free
pp可以使用，如果好盘上没有空间了，就无法进行操作了。如果主机本地还有空槽位，可以先增加一块盘到rootvg中，使用迁移命令将lv迁移到新硬盘中，然后在踢出故障硬盘。这里除了migratepv命令，可能还会用到migratelp命令，我们将会在最后一个场景中介绍。
2．如果故障硬盘彻底损坏，删除lv对应的文件系统，尽管好盘上的部分lv还是好的。
在unmirrorvg后发现故障盘上还存在lg_dumplv的lv，好盘上却没有。
1.如果故障盘还能读写，通过migratepv将lg_dumplv迁移到好盘上即可。
2.如果故障盘彻底损坏，按以下方式操作。
sysdumplv -l查看当前的primary dump设备；
在好盘上建立一个lv，取名dumplv，type设置为sysdump类型；
sysdumplv-P-p/dev/dumplv
sysdumplv -l 确认primary dump device已经改到新dump设备上；
删除lg_dumplv。
此时要使用原来lg_dumplv的名字，按照上述步骤在好盘上再建立一个lg_dumplv，再将primary
dump设备指向回来。这部分修改完成就可以按照正常换盘流程进行了。
当发现Paging
space空间除了hd6还有paging00并同时分布在两个盘且没有镜像，在Unmirrorvg后，报错硬盘上还是有paging00。这时候需要删除paging00，在镜像完成后确认是否再次创建paging
完成后将hdisk1上的paging00删除，走正常更换流程，更换完毕后，重新创建一个paging space
前面所说的都是rootvg中含有hdisk0和hdisk1两块硬盘的情况，如果rootvg包含超过两块硬盘，可按照以下方法操作。
多数情况下，硬盘过多是lv跨卷，使lv的镜像分布在多块硬盘上。
这时需要活用lsvg，lspv，lslv等命令准确的分辨出每块硬盘上lv及其他lv在不同硬盘上的镜像情况和分布情况。往往此时unmirrorvg不能达到理想的目的，所以最好使用rmlvcopy、mklvcopy等命令来精准调整lv在不同pv上的镜像情况。如果一个lv跨多个卷并且每一个pv上的free
pp都不能满足这个lv，就需要使用migratelv、migratelp等命令来调整lv的分布，最终达到更换故障硬盘的目的。
下面看一个例子，rootvg中存在4个pv，并且有硬盘大小不一致的情况。
首先通过rmlvcopy来解除lv的镜像关系
查看sapsoftlv的分布情况
假设hdisk1出现频繁报错，要将hdisk1上sapsoftlv的lp迁移到hdisk0和hdisk2上，通过migratelp来精准迁移。
将sapsoftlv分布在hdisk1上的lp分别迁移至hdisk0和hdisk2上后，使hdisk1上没有任何lv，就可以按照正常流程进行硬盘更换流程了。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。当 AIX 磁盘出现问题时
简介如果您曾经做过一段时间的 IBM ® AIX® 系统管理员或 SAN
管理，那么您就会对磁盘错误、文件系统问题和 Logical Volume Manager (LVM) 故障非常熟悉。如果其中某种情况发生了，您将如何应对呢？但是更好的是，如何提前预防这类情况的发生呢？
本文关注的是这类情况，即当好磁盘开始转坏。本文首先概述了磁盘错误及其分类。其后，介绍了硬件概念以及搭建设计良好的冗余环境的方式。进而讨论了危机情况下的应对方案。
磁盘错误分类我使用两个主要的度量值来分类 AIX 系统上的磁盘错误：影响和持续时间。影响 所量度的是磁盘错误的影响力及其对服务器的冲击。换言之，就是 “这会造成何程度的伤害？”。持续时间
所量度的是磁盘错误持续的时长和恢复时间，即 “这伤害将持续多久？”。
影响可分为四个主要级别：可用性丧失：当存储资源离线或断开与其管理服务器的连接时就会发生可用性丧失。虽然磁盘上的数据没有损失，但是无法访问该磁盘。例如：文件系统遭卸装或光纤通道适配器被断开连接。
数据丢失：由于逻辑或物理问题，数据无法写入磁盘或无法从磁盘读取。例如：LVM 写入错误。
跨多个磁盘的数据丢失：在这种情况下，不仅一个磁盘而是多个磁盘均遭遇了数据丢失。当逻辑卷跨磁盘条带化且其中一个磁盘故障时，常常会发生这种情况。
跨多个服务器的数据丢失：随着 SAN 技术的广泛应用，一个磁盘硬件可能受损到这样的程度：多个服务器均受到了数据丢失的影响。
同样地，持续时间也可用分为四个主要级别：暂时：这类磁盘错误不常见且只发生一次，不会带来真正的威胁。它只在服务器的
errpt 内出现一次，然后即消失。例如：一次糟糕的块重分配。
间歇：间歇错误的出现很不规律，可以由初期问题推断，比如若硬盘记录了一系列写入错误时，往往表明此驱动器可能会出现故障。
经常：就像是由一个 cron
作业定期安排的那样，以周、天、小时或分钟为间隔发生问题，这会对服务器形成严重威胁并具有广泛的有害影响。
永久：不太容易或者根本不可能从这类错误中恢复。缺乏可替换硬件，将不能从这种情况中恢复。
通过交叉参考表中的这两个度量指标，您就能够更好地了解磁盘错误的危急程度以及它们对服务器的影响。
提供了这样的一个示例表。
图 1. 磁盘错误的影响和持续时间指标的交叉参考 显示了一个四乘四的表。其中的列代表的是问题的持续时间，从左到右升序排列。行代表的是问题的影响，严重程度从下至上升序排列。表中的单元格按色谱进行了颜色编码，从左下角表示问题不怎么严重（比如可用性的临时丧失）的蓝绿色开始，一直到右上角表明问题比较严重（比如跨多个服务器的数据永久丢失）的橙红色。就我的经验而言，超过绿色区域均会产生严重的问题，并有可能会导致生产效率或业务上的损失。服务器进入黄色区域并带来灾难性后果的实例，我也只是见到过几次。
预防性措施磁盘是否 会出现故障从来都不是考虑问题，要考虑的问题是故障会在何时 发生。没有任何磁盘能够保证永远正常工作。所有好的系统管理员的目标是避免成为硬件平均故障间隔时间的受害者，并找到一种方式来减轻磁盘故障的风险。
所有 AIX 或 SAN 管理员的三个主要目标是最大化可用性、性能和冗余。您希望存储环境是可用的，即为了能确保按需访问数据也能有足够的磁盘空间来保存所有数据。磁盘也必须具有良好的性能以便应用程序不会被任何 I/O
等待所延误。此外，磁盘还需要具有冗余以便资源的故障不会妨碍服务器继续发挥作用。
通常，每一种最大化都会要在至少一个其他方面做出权衡。一个在可用性和性能上做到最大化的存储环境通常就不会考虑实现大量的冗余，因为针对速度做过优化的磁盘资源常常都会用尽最后一个可用比特。一个侧重于可用性和冗余的存储环境则很有可能读写速度较低，因为长期的稳定性是其追求的目标。而一个侧重于性能和冗余的解决方案则常常因为要获得高速 I/O 以及双倍的读写而占用更多的空间，这在可用的空间方面，的确降低了可用性。
AIX 提供了更多的实用方式可用来准备预防性措施。每个管理员都应该知道下列的几个常用概念：
避免单点故障。永远不要构建这样一个环境，即其中单个资源的丧失会损害整个环境。这样的一种架构通常只包含单个硬盘、单个光纤通道适配器或单个电源供所有设备共用。在这种情况下，资源必然会在最不恰当的时候瘫痪。
RAID 技术是最大化资源的一个很好的方式。多年前，工程师们开发了一种通过 RAID 技术将便宜的存储设备集中到一个较大的组群中的方式。AIX 已经融合了很多级别的 RAID
技术，且无任何其他的成本；这些技术可在软件级别上使用，比如条带化 (RAID 0) 和镜像 (RAID 1)。根据所使用的磁盘子系统的类型，还有其他的几个选项可用，比如具有分布式奇偶校验的条带化 (RAID 5)、条带化镜像 (RAID 0 + 1) 或已镜像条带化 (RAID 1 + 0/RAID 10)。
使用有效的 LVM 策略来隔离数据。管理员可能犯的最严重错误就是把服务器的所有资源如操作系统、第三方应用程序、页面空间以及应用程序数据等均置于单个卷组中。这么做会产生各种各样不好的后果，包括性能差、系统备份过多、可管理性受损以及故障发生几率增加。应该对服务器的各个方面进行评估和隔离，并将其资源放入各自卷组和存储类型。例如，可以将一个大型的数据库服务器设计成：拥有一个已经部署成镜像模式的 rootvg 磁盘，用于存储应用程序的 SAN 存储和分页空间，一些用于归档日志和高-I/O 交互的固态磁盘。
接下来，我们将研究 AIX 服务器上所使用的各种存储类型的策略。内部硬盘驱动器作为 AIX 中最常用的存储格式，内部硬驱常被用于根卷组磁盘以及占用空间较小的服务器。在使用内部硬驱时，第一步均要为每个卷组配置至少两个磁盘，并使用 mirrorvg 命令镜像这些硬盘驱动器。如果服务器是一个大型的 IBM
System p® 机，那么就需要跨多个抽屉 (drawer) 选择磁盘来最大化冗余，以防某个硬件如背板发生故障。同时，为了优化性能，最好使用 lspv –l 和
lspv –p 检查磁盘上逻辑卷布局来保持磁盘外沿上较高的-I/O 区域与逻辑卷相邻。
小型 SAN 存储对于需要更多内部磁盘空间来存储大量数据的环境来说，较小的存储子系统，如直接附加的 IBM FAStT 磁盘抽屉或较早的小型 SAN 技术，均是非常实惠的解决方案。对于这类情况，重要的是要密切管理环境的配置，因为过程中很有可能会出现一些单点故障。该存储必须通过适当的 RAID 配置进行优化，比如一个附带热备份磁盘的 RAID 5 设置。还要有两个能够访问这个抽屉的适配器以保证服务器端的可用性和冗余。为了让这些磁盘能够清楚地呈现给服务器，还应该安装并随时更新适当的软件驱动器，比如多路径 I/O 或一个子系统设备驱动器路径控制模块。大型 SAN 存储在大型的 SAN 存储环境中，多个服务器通过交换机访问多个存储设备，比如 IBM System Storage® DS8300 设备，通常也会有专门的 SAN 管理员来管理磁盘资源。但是从 AIX 角度看，系统管理员也可以帮忙做这些事，比如选择多个双端口光纤通道卡来与不同的光纤进行通信和改进吞吐量。如果使用了虚拟基础架构优化 (VIO) 技术，那么 N_Port ID 虚拟化 (NPIV) 可充许具有较低 I/O 需求的多个服务器通过同一个适配器进行相互通信，从而减少分配给 LPAR 的插槽数量。SAN 引导技术为 LPAR 提供了极快速的构建和引导时间，特别是在用 Network Installation Manager (NIM) 完成时，尤其如此。
恢复步骤磁盘故障的影响程度不一，从轻微的中断到整个的服务器故障。那么，当遇到故障时该怎么做呢？
第一步是检查磁盘资源的可访问性，从最高可用级别开始一直往下，在需要时使用 errpt 作为指导。如果服务器仍在正常运行，那么使用 df 或 mount
命令进行查看时文件系统是否仍然存在？如果没有，是否能用 lsvg
或 varyonvg 访问卷组，或是它已丢失了配额（quorum）？磁盘本身是否仍处在 Available 状态，或者使用 lsdev –Ccdisk
命令后，是否显示它们处于的是 Defined 状态？像执行
lspath 或 pcmpath query adapter
这样的 SAN 存储命令后，这些光纤通道设备显示的是离线还是丢失？当通过 Hardware Management Console 查看时，服务器仅是宕机并处于 Not Activated 状态？大型的 System p 机器或 SAN 子系统宕机了？不要只是因为某一类资源可用而贸然做这样的假设；所有类似资源都必须处于可用状态，所以务必全面检查。
第二步是检查资源的完整性，从最低的可用性等级开始向上检查。服务器是否成功引导？系统启动时是否出现故障，如带有数字 552、554、
或 556 的 LED 消息（毁坏的文件系统、JFS 或 Object Data Manager [ODM]）？如果系统仍在正常运行，那么执行 cfgmgr 命令后，磁盘资源是否会重新联机并回到 Available 状态？卷组是否可由 varyonvg 命令激活？文件系统是否完全载入？想要查看的数据是否能出现在文件系统内，还是丢失了？
第三步是按具体情况具体分析的方式解决资源问题。以下是我在多年的修复问题过程中常常使用的一些技巧：
文件系统。以我的经验，这是最常见的一种磁盘错误。无需多费劲就可以让超块变脏、造成存储碎片、搞乱存储节点或引起 errpt 反复出现 JFS 错误。即便是一个完整的文件系统也可能会把事情搞砸。修复文件系统问题最好的策略也是最简单的：利用文件系统检查命令 (fsck)。在这些情况下，我会卸载文件系统并针对它们运行 fsck –y ，直至不再出现错误，然后再重新载入它们。有时，我会格外彻底地卸载一个卷组内所有的文件系统，并使用外壳脚本中的循环脚本来完成此项任务以防出现潜在问题。
卷组。问题若超出了文件系统的范畴时，通常会转向卷组级别。有时，问题是 ODM 级的，可以通过 syncvg
或 synclvodm 进行纠正。在紧要关头，我曾用 varyoffvg 关闭卷组，用 exportvg 导出它们，然后用
importvg 重新导入它们以使其能被正确识别。但我总是会提前备份好 /etc/filesystems 文件并记录下磁盘端口 VLAN
ID (PVID) 以保存载入的顺序。
物理卷。谈到 PVID，我看到过磁盘丢失，然后再以不同的 PVID 重新回到服务器。一个有帮助的做法是定期在别处记录下磁盘信息作为比照以防这类事情发生。如果真的发生了，我通常会用
rmdev –dl 从服务器删除这些磁盘，再用
cfgmgr 重新检测它们，然后再导出并重新导入卷组。
SAN 连接。有时全局名称 (WWN) 并不跨 SAN 网络进行端对端的传播，比如 VIO 服务器上的 NPIV。我有时会通过运行 pcmpath set adapter offline 禁用光纤通道适配器并手动定义或检查 WWN，然后再重新开启适配器。我也做过最极端的事，就是探查电缆并检查另一端是否有灯亮以确保没有物理问题存在。
引导问题。如果想要判断一个服务器为何在磁盘故障后不能引导，我通常会做的第一件事情是从服务器（根卷组除外），断开所有磁盘的映射和连接。如果为了找到一两个 rootvg 磁盘而探查数百个磁盘，那么将花去 Software Management System (SMS) 大量的时间。因此，我会在维护模式从一个 NIM 服务器引导系统来运行诊断并修复文件系统，用 bosboot 命令重新创建引导逻辑卷或访问此根卷组来修复诸如 /etc/filesystems 的配置文件。而且，在服务器启动后，有问题的文件系统通常都是那些本身处于关闭状态而它们旁边其他的文件系统则载入正常的文件系统。
恢复。最后，如果有东西损坏并确实需要修复，就要确保新更换的部件尽量接近于原始设备。这样一来，就可以最大限制地减少处理像文件系统大小或软件驱动器这类占用修复时间的操作。我一直建议要为做好系统备份（mksysb 映像和使用诸如 IBM Tivoli® Storage Manager 的产品）来应对数据丢失和无法恢复的最坏情况。
结束语避免好的磁盘转坏所带来的影响和问题持续时间太长的最佳做法是不要在问题出现后才去解决问题，而是要设法最大限度地利用 AIX 环境的可用性、性能和冗余来提前防止这些错误的发生。但是如果错误确实发生了（因为故障在所难免），则应该验证它们的可访问性和完整性，并设计出增量计划 (incremental plan) 来修复它们，使您的服务器重新正常运行。
有关 LVM 的更多信息，请参阅
有关 LVM 故障排除的更多信息，请参阅
eServer Certification Study Guide
了解如何 （Chris Gibson，
developerWorks，2010 年７月）。
查阅 IBM 红皮书 。
：developerWorks 的“AIX and UNIX 专区”提供了大量与 AIX 系统管理的所有方面相关的信息，您可以利用它们来扩展自己的 UNIX 技能。：AIX and UNIX 专区已经为您推出了很多的技术专题，为您总结了很多热门的知识点。我们在后面还会继续推出很多相关的热门专题给您，为了方便您的访问，我们在这里为您把本专区的所有专题进行汇总，让您更方便的找到您需要的内容。：在这里你可以下载到可以运行在 AIX 或者是 UNIX 系统上的 IBM 服务器软件以及工具，让您可以提前免费试用他们的强大功能。：本杂志的内容更加关注于趋势和企业级架构应用方面的内容，同时对于新兴的技术、产品、应用方式等也有很深入的探讨。IBM Systems Magazine 的内容都是由十分资深的业内人士撰写的，包括 IBM 的合作伙伴、IBM 的主机工程师以及高级管理人员。所以，从这些内容中，您可以了解到更高层次的应用理念，让您在选择和应用 IBM 系统时有一个更好的认识。。下载试用版本，登录在线试用，在沙箱环境中使用产品，或是通过云来访问。有超过 100 种 IBM 产品试用版可供选择。
添加或订阅评论，请先或。
有新评论时提醒我
static.content.url=http://www.ibm.com/developerworks/js/artrating/SITE_ID=10Zone=AIX and UNIXArticleID=777712ArticleTitle=当 AIX 磁盘出现问题时publish-date=AIX系统怎么查看硬件信息 - ITeye问答
AIX系统怎么查看硬件信息，比如内存，CPU，硬盘，网卡等。
采纳的答案
查看内存
使用命令#& lsdev -Cc memory
或者
#bootinfo -r
查看物理内存
prtconf就可以查看系统所有的信息 cpu 内存 硬盘等..
显示每一个CPU的频率
#pmcycles -m
查看机器型号，SN
＃uname -Mu
百度上找找吧
这个百度一下就有很多答案了
参考这个吧 比较齐全
已解决问题
未解决问题