简介HP9000小型机管理员必读文档是一份面向惠普HP9000系列服务器系统管理员与运维人员的实用参考资料重点讲解HP-UX操作系统基础、硬件结构及故障排查方法。全文分为机房环境、故障诊断、系统管理员日常工作等章节既涉及机房温度湿度和电源散热要求也覆盖硬件部件检测、软件日志分析与网络连通性定位同时梳理了HP-UX常用命令、逻辑卷管理、系统安全、性能观察、PDC与主控台配置等日常维护要点并给出了借助惠普响应中心电话或远程访问服务的协同排障路径。资源包为单份doc文档大小284KB结构清晰可按章查阅。目前已有118人学习下载适合刚接手HP9000平台或希望系统整理小型机运维知识的技术人员有助于快速建立从环境规划、日常巡检到应急排障的完整工作框架。1. HP9000 小型机管理员的知识边界与职责HP9000 是一代运维人的集体记忆。它以 PA-RISC 芯片为心脏跑的是专属的 HP-UX 系统和今天遍地都是的 x86 Linux 服务器完全是两种物种。金融清算、电信计费、制造 MES许多关键业务至今还压在这些铁疙瘩上。作为管理员你未必能决定它何时退役但一定能决定它是否稳定撑到退役那天。接手一台 HP9000最紧迫的不是急着敲命令而是先把三件事理顺硬件固件的介入方式、LVM 卷管理的操作习惯、以及一套不依赖图形界面的排障思路。这篇文章会把这三条线串起来从引导流程到日常运维再到故障时的急救手段全是能直接落地的做法。2. 从 PDC 到 vPARHP9000 的引导链路与维护模式2.1 PA-RISC 固件的分层结构HP9000 的引导链路和 x86 完全不同。x86 主板上的 BIOS/UEFI 只管初始化硬件然后跳转引导加载器HP9000 的固件分了两层最底层叫 PDCProcessor Dependent Code类似 BIOS上层叫 iPODInitial Program Loader或者针对客户机的 BOOT_ADMIN 界面。管理员日常接触最多的是 PDC 菜单和 BOOT_ADMIN 提示符误入 PDC 后第一反应不该是重启机器而是要认清当前处于哪一层。进入 PDC 通常在开机自检时按 ESC 键或者等待倒计时中断。不同型号触发方式有细微差别但进入后都会看见主菜单选项不外乎 Boot、Information、Service、Configuration 几类。关键认知是PDC 是机器的最后防线在 PDC 层可以查看 CPU 数量、内存大小、Boot Path 列表也可以修改引导设备的优先级偶尔调整 L2 cache 大小。2.2 引导设备优先级修改与 BOOT_ADMIN进入 BOOT_ADMIN 之后最实用的命令是search它会自动探测所有可引导的 SCSI 或 Fibre Channel 设备并返回设备路径和是否可引导的标志。管理员需要记住HP9000 的引导设备路径是类似这样的字符串0/0/2/0.0.0.0.0.0.0或0/0/1/1.0.0.0.0.0.0这些路径由硬件槽位编号和 SCSI/FCP 地址组成无法靠背路径和记忆去猜必须借助search结果来确认。修改默认引导路径的做法如下Main Menu: Enter command boot BOOT_ADMIN search BOOT_ADMIN boot 0/0/2/0.0.0.0.0.0.0 BOOT_ADMIN bootpath 0/0/2/0.0.0.0.0.0.0 BOOT_ADMIN autoboot onbootpath是写死默认引导路径autoboot on是让机器以后开机自动引导避免每次停在 Main Menu 等人干预。如果磁盘阵列更换了控制器导致路径变化或新装了镜像盘需要切换引导盘这套search bootpath autoboot流程就该手到擒来。建议在完成任何磁盘阵列变更后立刻执行bootpath更新否则下次重启可能卡在固件菜单里远程无法解决只能跑机房。2.3 常见引导故障的判别引导故障大概分成三类PDC 料不到硬盘、内核可以加载但 rootvg 所在的/stand挂不上、文件系统损坏后进入单用户模式失败。三者的症状判别用一张表消化故障现象可能原因常用手段PDC 菜单中 search 看不到系统盘SCSI ID 冲突、光纤链路中断检查 SCSI 地址或 FC 交换口状态停在 boot 提示符显示 Boot IO Dependent Code (IODC) Error引导路径失效或设备离线用search重新确认路径并修改 bootpath内核加载后提示 Panic: not enough memory for kernel自动 boot 内存参数设置过大在 BOOT_ADMIN 中调整boot参数减少内存预留处理引导故障的底线原则是不拆分已有链路。更换硬盘、变更 HBA 卡槽位前先记下现有 bootpath写入维护记录。而 vPAR 环境更需要把vparboot与 PDC 菜单的关系搞清楚——在 vPAR 下 PDC 菜单的引导设备是 vPAR 宿主机的引导设备vPAR 的引导参数放在自己的启动配置里二者不要混为一谈。3. HP-UX LVM 卷管理的日常运维与扩容实操3.1 HP-UX 与 Linux 卷管理的差异在 Linux 上我们讲 LVM2在 HP-UX 上同样的术语是 LVM但内部行为有差异HP-UX 的 root 卷组是 rootvg逻辑卷设备名固定为/dev/vgXX/lvolN形式而物理卷可以用 PV 头识别。管理员最容易栽的坑是在 HP-UX 中给逻辑卷扩容后文件系统不会自动扩展必须手动执行扩展。这与 Linux 的lvextend后还要resize2fs的情形一致但 HP-UX 的默认操作手法和参数完全独立。日常巡检中查看卷组状态的标准命令组合是# 查看所有卷组 vgdisplay -v # 只查看 rootvg 的物理卷分配 pvdisplay -v /dev/dsk/c1t2d0 # 查看逻辑卷映射关系 lvdisplay -v /dev/rootvg/lvol5注意习惯加-v因为只有 verbose 模式才会输出物理盘上的扩展块落点。如果省略-v你只看到容量大小看不到 PE 到盘的对应关系——排查坏道时这种对应关系恰恰是关键线索。3.2 在线扩容一块逻辑卷的完整步骤生产环境的 HP9000 扩容不像测试机随便删了重建就行。标准做法必须在线完成零中断。步骤可以总结为四个阶段3.2.1 物理卷就绪新磁盘接入后需要对整块盘做 PV 化# 初始化一个物理卷 pvcreate -f /dev/rdsk/c2t3d0这里的-f是强制覆盖旧的卷头/dev/rdsk用字符设备而非块设备是 HP-UX 的一个重要习惯。务必记得用rdsk做因为 LVM 在 HP-UX 上对原始的块设备文件操作不如字符设备可靠。3.2.2 扩展卷组# 把新盘加入 datavg vgextend datavg /dev/dsk/c2t3d0如果卷组内做镜像还要用vgextend加入 Mirror 盘然后用lvsplit或lvextend的镜像参数来同步。3.2.3 逻辑卷扩容# 把 lvol3 增加 2GB lvextend -L 2048 /dev/datavg/lvol3注意参数HP-UX 的-L默认单位是 MB-l默认单位是 PE 数。想追加 2GB-L 2048直接把总容量设为 2048MB。这里与 Linux 的-L 2G不一样HP-UX 老版本对追加写法兼容度差稳妥做法是算好总容量再设置。3.2.4 文件系统扩容如果是 VxFS 文件系统HP-UX 的主流文件系统执行# 在线扩展 VxFS 文件系统到逻辑卷全部容量 fsadm -F vxfs -b 2097152 /datavg/lvol3这里的-b参数指定文件系统的总块数块大小默认 1KB所以 2GB 对应 2097152 块。VxFS 支持在线扩展是生产环境不需要卸载文件系统的关键。如果是 HFS 老格式则必须卸载后再用extendfs操作但这类文件系统已经很少见不做优先讨论。3.3 镜像卷组的拆分与重建做卷镜像的运维人员比例不低但镜像后的拆分回退往往忘了怎么做。镜像拆分常用在备份前想拿到一份一致性的 lv 快照。# 查看当前镜像状态 lvdisplay -m /dev/datavg/lvol5 # 拆分镜像 lvreduce -m 0 /dev/datavg/lvol5 /dev/dsk/c3t1d0如果拆下来的物理卷还需要继续承担数据盘记得用pvremove剥离这个盘上的 PV 标记。否则下次进 vgscan 时会发现 PV 仍被卷组引用导致卷组信息不一致。这里额外提醒HP-UX LVM 对掉盘的处理相当严峻。某个 PV 不可用后卷组默认进入 partial 状态此时做 vgchange -a y 不会报错但逻辑卷如果横跨掉盘区域I/O 错误直接暴露给上层应用。处理这类问题的第一反应不是vgextend加盘而是先评估是否做镜像恢复、是否有log设备可以回放接着用pvdisplay和lvdisplay -v交叉确认故障盘的 PE 分配范围。4. Ignite-UX 系统安装与软件管理的实用命令4.1 Ignite-UX 的最小可用方案Ignite-UX 既是安装工具也是备份恢复利器。HP9000 上跑生产真正的系统安装操作不常见但管理员至少要做一次 Ignite 备份——这和 Windows 上做系统镜像、Linux 上定期 tar 根是同类诉求只不过设备路径和工具名不同。常见做法是在一台 Ignite-UX 服务器上配置/etc/opt/ignite/instl_boottab从而给客户端机器提供引导安装。但如果环境里没有专门的 ignite 服务器最简单的莫过于从本机做一次磁带或者磁盘备份/opt/ignite/bin/make_tape_recovery -a -x-a表示全自动-x表示不要交互。系统会先创建 Ignite 恢复格式的备份写到磁带或指定的备份文件。注意这套命令不能替代数据文件备份它是做系统级灾难恢复的。数据还是要走 VxFS 快照工具fssnap或备份软件。恢复阶段带外引导把磁带作为启动设备进入 Ignite 界面后选 Recovery即可把系统恢复到备份时间点的布局包括卷组、逻辑卷和文件系统。这套工具在系统盘损坏时的价值无法估量建议纳入日常月度检查项。真正跑恢复演练的管理员不多但演练过的在关键故障时完全是两种状态。4.2 用 swinstall 管理软件包HP-UX 的包管理体系和 RPM 完全不同。RPM 管的是二进制 RPMHP-UX 用 depot 来分发软件并用 Software DistributorSD工具来管理。常用命令速查表操作命令查看系统已装的所有 bundle 和 filesetswlist查看某个软件是否安装及版本swlist -l product从本地 depot 安装swinstall -s /path/to/depot name卸载某个 filesetswremove name校验软件文件是否完整swverify name实际安装前一定先跑swinstall -p做预检查。-p是 preview只做分析并输出影响不实际安装。在多用户环境下软件安装必须放在交互式会话中执行避免 Telnet/SSH 断线导致安装过程挂起。代码形式如下swinstall -s /tmp/depot -x mount_all_filesystemsfalse -m B5725AA # 常用参数解释 # -s 指定 depot 源路径 # -x mount_all_filesystemsfalse默认会自动挂载所有文件系统容易出现额外副作用生产环境关闭更好 # -m 指定安装介质名4.3 补丁管理的顺序陷阱HP9000 的补丁体系比重装系统更考功底。先装补丁还是先装 bundle 的顺序错误时系统会出现依赖状态不一致swverify会报缺失 prerequisites但实际缺失的 fileset 已经在系统里存在——这是 SD 工具的经典误报。最稳妥的策略是所有补丁统一通过swinstall -s安装到同一个 depot然后用swjob分批次规则写入安装队列避免手动零散装几个补丁后造成影藏冲突。补丁安装后,不需要重启的情况占大多数但内核补丁如 PHKL 系列必须重启。管理员经常忽视swlist -l fileset | grep PH的输出格式——补丁是嵌在 fileset 层级之下的。只看 bundle 列表看不了补丁的版本所以巡检补丁状态一定加上-l fileset选项这一行命令能省去每一次打开 PDF 查补丁文案的时间。5. HP9000 小型机性能监控与故障诊断要点5.1 慢查询还是系统慢先看全局再定位接手一台卡顿的 HP9000最忌讳的是直接跑某个应用层查询来试状态。一线排查顺序必须从全局往局部收先看负载 ——sar、vmstat反映 CPU 和内存再看 I/O——iostat看磁盘的 await 和 busy最后才到应用层。键入环境变量时注意# CPU 负载若大于 CPU 逻辑核数基本可判定 CPU 瓶颈 sar -u 5 5 # 报告物理内存利用率以及 swap 使用量 sar -r 5 5 # 实时看整个系统的进程运行状态和三态切换 vmstat 5 10vmstat的procs r列如果持续超过 CPU 核数说明运行队列溢出。sar -r报告的pswpin/s最好长期为零否则内存压力已经大到需要频繁换入换出。HP9000 上另一个核心工具是glance。在系统缓慢、perf 数据分散时glance的交互模式可以按d磁盘、m内存、gcpu 全局切换视图。更重要的是它对进程列表提供了动态的 top CPU/top MEM 排名这在 Linux 的top效果类似但 Glance 对卷组 I/O 和内部 LVM 层做的采样更细比如能看到某个逻辑卷的平均服务时间。5.2 日志与消息流转的查看手段HP-UX 的日志系统分散在两处/var/adm/syslog/syslog.log是系统主要日志/var/adm/syslog/目录下还可能有auth.log、mail.log等其他设施的日志。排查硬件故障时还不能跳过smt工具它收集硬件类日志和传感器状态。# 查看硬件健康状态 /opt/sysmgmt/sbin/smt top # 模拟系统管理事件看错误登记 /opt/sysmgmt/sbin/smt log -s如果硬件报警smt log -s会输出类似 cell sync、CPU soft error 的条目。这类故障偶尔是瞬时性的不必过度紧张但连续出现必须排空。5.3 内存转储与 dump 分析系统 panic 后将进入 crash dump 捕获环节很多管理员不知道如何判断 dump 已经正确地被保存。HP-UX 默认把 dump 写到设备节点/dev/dump对应的交换区中可以在启动时查看kcrash信息。检查实际 dump 文件# 检查 dump 状态 /usr/sbin/crashconf -d # 如果系统已经重启并准备分析 dump crashed /dev/dump分析 dump 其实不需要直接解读机器码。HP-UX 自带的xdb可执行宏定义来输出调用栈。没有 xdb 经验的管理员优先用crashconf -d确认 dump 保存的设备和大小是否符合预期再将 dump 文件转出到一台 Linux 工作站离线分析。5.4 基于 PDC 诊断跑一遍基础硬件体检设备有过热或掉电风险时不妨进入 PDC 菜单执行Main Menu: Enter command service Service Menu: Enter command fastboot on Service Menu: Enter command selftestselftest将重启并对 CPU、内存、Cache、I/O 桥接器依次跑内部测试。结果输出在控制台遇到 error 项再结合smt log的详细报警定位到具体板卡。这一步的价值在于操作系统层面的/var/adm/messages往往只能显示设备 disconnect但不能告诉你哪根内存条坏了PDC 的 selftest 相比 OS 层命令更接近硬件本身。写入周期性检查项目时建议每季度做一次selftest同时记录 CPU 温度和风扇转速。对老旧机型而言内存隐性损坏引发的奇偶校验错误通常就是通过这些固件级的检查最早暴露出来的。本文还有配套的精品资源点击获取