企业官网建设流程全解析

1. 一套缩写，差点让我在扩容当晚翻车

1.1 初次面对这五个缩写时的真实场景

刚转做系统运维那阵，我接手了一台运行着核心业务的 AIX 小型机。业务方晚上七点提了扩容工单：数据目录剩余空间不到 5%，希望当晚完成翻倍。我那时候对 Linux LVM 已经有了点使用基础，脑子里默认的计划格外清晰——加一块盘，做成 PV，塞进 VG，再把 LV 撑大，最后 resize 文件系统。

结果登录机子之后，命令完全不对路。pvcreate不存在，lsvg倒是有，可我看不懂输出里那些 LP、PP、VGSTATE、VARYON 到底在说什么。最尴尬的是，我连该扩的是"LP"还是"PP"都没想明白，下mklv命令时差点把卷组可用分区算错。最后靠同事远程指导，按"先加物理卷、再扩展卷组、再改逻辑卷大小、再扩文件系统"的顺序一步步补完，才没造成业务中断。

那次经历给我留下非常深的印象：VG、PV、PP、LV、LP 这五个缩写，不是同一套体系里的五胞胎，而是层层递进的五层存储架构。少理解任何一层，关键时刻都会出错。

1.2 这五个缩写解决的是同一个核心问题

把这些缩写背后的问题翻译成大白话：怎么把一个物理硬盘的能力，变成业务系统随时可以调整大小的逻辑盘。物理硬盘买回来就那么大，分区一改就要动业务，实在太僵化。LVM 的思路是在物理硬盘和文件系统之间增加一个抽象的中间层，让空间可以跨盘聚合、在线伸缩、动态迁移。PV、PP、VG、LV、LP 就是这个中间层在不同尺度上的零件。

• PV（Physical Volume，物理卷）：物理硬盘在被 LVM 收纳后的身份。
• PP（Physical Partition，物理分区）：AIX 里物理卷上空间分配的最小单位。
• VG（Volume Group，卷组）：多个物理卷聚合成的资源池。
• LV（Logical Volume，逻辑卷）：从资源池里切出来、真正给业务使用的逻辑盘。
• LP（Logical Partition，逻辑分区）：逻辑卷内部的基本组成单位，负责把逻辑空间映射回物理空间。

需要说明的是，这套带 PP 和 LP 的叫法是 AIX 体系里的标准说法。Linux 的 LVM 简化了一些，没有 LP 这一层，分配单位叫 PE（物理扩展）和 LE（逻辑扩展），映射基本是一比一。两种体系的核心思想一样，但细节差别会直接影响命令和排查思路，所以后面我专门用一整章做对比。

1.3 什么样的人需要把这套体系吃透

第一类是最直接受益的：AIX 小型机管理员，日常做卷组、逻辑卷、文件系统扩容、镜像和故障恢复，全部绕不开这五个词。第二类是从 Linux 转过来或者两种平台都要维护的运维工程师，理解了 AIX 的 PP/LP，再回看 Linux 的 LVM 会非常轻松。第三类是云环境里的后端开发和存储规划人员，虽然平时面对的是块存储、云盘和卷，但真正要理解为什么一个卷可以先在线扩容再重新挂载，底层依然是这套物理卷、卷组、逻辑卷的模型。

这篇文章不会只讲概念。每一章都会给出命令走查、真实场景里的排查思路，以及我在维护环境里总结的检查清单。看完可以直接拿命令套路去自己的实验环境里试一遍，再对照手册理解参数，效率会高很多。

2. 从物理盘到逻辑卷：把 VG、PV、PP、LV、LP 按层级摆顺

2.1 PV：物理卷是存储世界的"地基"

在 AIX 里，PV 通常对应一个hdisk设备，它可能是一块物理磁盘、磁盘阵列中划分的 LUN，或者虚拟化平台映射出来的 vdisk。一个 PV 被纳入 LVM 管理前，需要先初始化，相当于给这块盘打上 LVM 的识别标签，记录盘上有哪些 PP、哪些 PP 已分配、哪些还没分配，这些信息保存在盘上的固定位置。Linux 里这一步是pvcreate，AIX 里通常在创建卷组时由mkvg顺手完成，不需要单独执行。

PV 的一个关键特性是：它被划入某个 VG 之后，就不再以"一整块盘"为单位去参与分配，而是以 PP 为单位。所以哪怕两个 PV 大小不一样、来自不同厂商，只要进同一个 VG，它们的地盘就能被统一调度。这一点和 Linux LVM 非常接近：底层细节被隐藏，上层只看到卷组里有多少可用空间。

我见过的常见误区是：有人以为 PV 等于盘上的某个分区，比如/dev/sda1。实际上在传统 LVM 里，PV 可以建立在整块盘上，也可以建立在独立分区上；在 AIX 里更常见的是直接用整个 hdisk。分区和 PV 是两回事，分区表是操作系统的磁盘分区概念，PV 是 LVM 资源池的入池单位。

2.2 PP：AIX 分配空间的最小刻度

PP 是 AIX LVM 里最有特色的概念。它把 PV 这块物理卷进一步切成固定大小的"格子"，卷组内所有 PV 的 PP 大小必须一致。PP 大小在创建卷组时确定，比如mkvg -s 8表示每个 PP 是 8MB。之后如果要在卷组里创建逻辑卷，空间需求会被换算成需要多少个 LP，LP 再指向具体哪个 PP。

为什么要有这个"格子"？因为在没有 PP 抽象之前，一块盘上的空间要么被整个分区占用，要么用非常复杂的起止扇区记录来管理，扩容、缩容、镜像都非常痛苦。有了固定大小的 PP，LVM 做三件事都很方便：一是分配空间时只要数格子；二是做条带化时可以在不同 PV 上取固定格子交替排布；三是做镜像时能轻松维护同一份逻辑数据对应两个物理格子的映射关系。

PP 大小的选择是个权衡：太小，映射表细，粒度灵活，但管理开销和元数据占用更高；太大，映射表粗，管理省事，但逻辑卷扩容时会浪费空间，而且一些场景下"差一点就够用"的小卷会特别尴尬。我维护的 AIX 环境里，业务数据卷组常用 4MB 或 8MB 的 PP；如果是大数据平台一类的大单体文件系统，会考虑 64MB 或更高。这个没有绝对标准，取决于你的卷数量级和增长节奏。

2.3 VG：把一堆 PV 收纳成一个资源池

卷组是整个 LVM 的调度中枢。一个 VG 可以包含一个或多个 PV，VG 建立后，所有 PV 上的 PP 被统一编号管理，形成一个跨磁盘的"大仓库"。业务系统看到的逻辑卷全部从 VG 里切，至于这个逻辑卷的底层落在哪块盘上，由 LVM 根据映射策略决定，业务和文件系统都不需要关心。

查 VG 状态，AIX 里用lsvg，单个 VG 的详细情况用lsvg datavg，查看某个 VG 里有哪几个 PV 用lsvg -p datavg。输出里常见VG STATE为active或inactive，这对应 AIX 的"卷组已激活/未激活"概念。卷组必须先 varyonvg 激活，里面的逻辑卷才能被系统访问；维修时可以先 varyoffvg 再处理磁盘。这个机制比 Linux 的 VG 激活逻辑更容易让人理解硬件维护要做什么。

Linux 里没有 varyonvg，但vgchange -a y相当于激活。概念迁移的时候，用 AIX 这套"卷组仓库 + 逻辑卷切割 + 物理卷入池"的模型去理解 Linux 的vgs、pvs输出，会顺畅得多。

2.4 LP 与 LV：逻辑侧的一体两面

LV 是业务能看到的"盘"。在 AIX 上可以用mklv创建后格式化，也可以用crfs直接创建一块带文件系统的文件卷。LV 内部由 LP 组成。LP 大小和 PP 大小一致，但 LP 的作用是把"逻辑侧的空间计量"和"物理侧的空间计量"解耦。

怎么说呢？创建逻辑卷时，你告诉系统"我要 500 个 LP 的空间"，系统会先在逻辑层分配 500 个 LP，然后在物理层给每个 LP 映射 1 个 PP。如果没做镜像，一个 LP 对应一个 PP，逻辑空间和物理空间一样大。如果做了双份镜像，一个 LP 会对应 2 个 PP，逻辑空间不变，物理占用翻倍。所以 LP 和 PP 之间的映射关系，才是 AIX LVM 能实现"逻辑大小不变、物理冗余翻倍"的关键。

当你用lsvg datavg看卷组信息，会发现有Used PPs和Free PPs两个指标，它统计的是物理分区层面的占用；而lsvg -l datavg看到的是每个逻辑卷占了LPs，同时会显示PPs。这两列数值在无镜像时相同，有镜像时 PPs 会是 LPs 的副本倍数。我在排障时经常先看这两列，一旦发现某个 LV 的 PPs 明显大于 LPs，第一反应就是"这个卷是不是带着镜像"。

2.5 一个直观的计算例子

假设卷组 datavg 由两块 64GB 的裸盘组成，创建卷组时指定 PP 为 8MB。那么每块 PV 有 8192 个 PP，卷组一共 16384 个 PP。现在要在 datavg 里创建一个 64GB 的逻辑卷，不做镜像，需要至少 8192 个 LP，每个 LP 映射到 8MB 的 PP，总物理占用 64GB。

如果业务要求给这个逻辑卷做双份镜像，LP 数还是 8192，但每个 LP 需要映射 2 个 PP，总物理占用变成 128GB。此时卷组里依然有剩下的 PPs 可以分配，但总量只够再切一个 64GB 的无镜像逻辑卷。把 LPs 和 PPs 分开统计后，容量规划就变成了"逻辑容量按 LP 数算，物理容量按 PP 数算，镜像会放大物理占用"。

这个例子很小，但足够说明一个问题：在 AIX 环境里做容量规划，不能只看"卷组还剩多少空间"，要看它统计的是 LP 视角还是 PP 视角。否则你以为还能再扩 80GB，实际上镜像卷已经把底层 PP 耗得差不多了。

3. AIX 的 PP/LP 和 Linux 的 PE/LE 不是一回事

3.1 Linux LVM 的三层模型更简单，也够用

Linux 的 LVM2 核心模型只有 PV、VG、LV 三层。物理卷内部以 PE（Physical Extent，物理扩展）为最小分配单位，默认大小 4MiB，创建 VG 时可调。逻辑卷由 LE（Logical Extent，逻辑扩展）组成，正常情况下一个 LE 映射一个 PE，一比一对应。

所以用 Linux 的朋友看lvs输出，只会看到 LV 的大小，不会在逻辑卷内部看到一个独立的"LP 数"。创建逻辑卷时指定大小就好：-L 100G就是 100GB，-l 80是按 80 个 LE 来切，后者很少用。PE 的大小决定了分配的粒度，比如默认 4MiB 时，100GB 的逻辑卷实际上由 25600 个 PE 组成。

Linux 也有镜像和条带，但实现方式与 AIX 不同。Linux 的镜像在 LVM2 中本质是通过 raid 机制完成，lvcreate --type raid1 -m 1或者lvconvert --type raid1。底层它依然用 PE 做资源分配，逻辑侧没有额外的"逻辑分区"层。好处是命令直观、输出简单；代价是你无法像 AIX 那样直接在 LV 创建时用copies参数轻量定义镜像副本数，需要额外理解 raid1 的内部映射关系。

3.2 AIX 的 LP 多出来的那一层，换来了什么

AIX 把 PP 和 LP 分成两层，核心目的是"物理层的灵活布局"。同一份逻辑数据在物理盘上可以放 1 份、2 份甚至 3 份副本，而逻辑侧的 LP 数量保持不变。这个设计让镜像、条带化、跨 PV 分配等都变成了"物理映射策略"，逻辑卷本身不必变化。

举个例子，一个 100GB 的 AIX 逻辑卷，可以把它做成双份镜像，两个副本分布在两个不同的 PV 上。此时若某一块 PV 出现故障，系统可以通过镜像副本继续提供服务，管理员再想办法把故障盘换成新盘、重新同步镜像。这种机制对数据库这类不能接受长时间业务中断的场景非常有价值。AIX 之所以长期运行在核心生产系统上，这个成熟度很高的卷管理能力是重要原因之一。

反过来说，LP 这层也会带来学习成本和管理复杂度。初学者看到lsvg -l里的 LPs、PPs 两列经常会懵；创建逻辑卷时的mklv -y applv -t jfs2 datavg 100M和 Linux 的lvcreate参数习惯也完全不同。可一旦理解了"LP 管逻辑刻度、PP 管物理刻度、映射关系由 LVM 维护"这个核心，所有输出都能对上。

3.3 关键差异对照表

这张表是我自己记忆两种体系时最常用的速查。Linux LVM 也有快照、精简配置等功能，AIX 在部分高级特性上的实现方式不同，但用表里这套主干去对应日常使用已经足够。

4. 实战：从一块裸盘到可用的文件系统

4.1 环境准备与常用查看命令

不管 Linux 还是 AIX，动手之前先把当前状态摸清楚。Linux 上先用lsblk看新增磁盘的盘符和容量，认准/dev/sdb这类设备名；然后用pvs、vgs、lvs快速浏览现有卷组剩余空间，避免把新盘加到错误的卷组里。

AIX 上对应的流程是：lsdev -Cc disk查看系统识别到的物理卷，lspv查看每个 hdisk 是否已经被分配给某个 VG，lsvg -o列出当前已激活的卷组。如果你拿到一台存量很大的机器，lsvg -l datavg能一次性列出该卷组下所有逻辑卷和对应的 LP/PP 占用，是排查空间问题的首选命令。

这个"先看清再动手"的习惯，比任何一条命令都重要。我见过不少同事拿到新盘就直接pvcreate+vgcreate，结果把本应并入业务卷组的新盘单独建成了一个空卷组；或者反过来，想加盘却加错了卷组。多敲一条查看命令，五秒钟的事，能省下后面一个小时的回滚。

4.2 Linux 路线：pvcreate / vgcreate / lvcreate 串联

下面这组命令在大多数环境里可以正常跑。假设新增设备是/dev/sdb，要做成一个卷组data_vg，然后从里面切一个 100G 逻辑卷挂到/data。

# 1. 查看新盘 lsblk /dev/sdb # 2. 创建物理卷 pvcreate /dev/sdb # 3. 创建卷组，名字叫 data_vg vgcreate data_vg /dev/sdb # 4. 创建逻辑卷 app_lv，大小 100G，从 data_vg 里切 lvcreate -n app_lv -L 100G data_vg # 5. 格式化并挂载 mkfs.xfs /dev/data_vg/app_lv mkdir -p /data mount /dev/data_vg/app_lv /data # 6. 验证 pvs vgs lvs df -h /data

有一点要特别提醒：如果将来还要扩容，建议先把卷组预先做好"富余空间"，或者预留一块备用 PV。因为lvcreate用完 VG 全部空间后，LV 大小就顶到天，想扩就得先做vgextend再加新 PV，步骤不复杂，但需要维护窗口。不如一开始就把 VG 做大一点，LV 按实际需求切，后续靠lvextend和xfs_growfs在线扩展。

4.3 AIX 路线：mkvg / mklv / crfs 的标准姿势

AIX 上也分两步：创建卷组和创建文件系统。假设新增物理卷是hdisk1，准备把 PP 设为 8MB，卷组名datavg，再从里面创建 JFS2 文件系统挂到/data。

# 1. 查看磁盘 lsdev -Cc disk # 2. 创建卷组 datavg，PP 大小 8MB mkvg -y datavg -s 8 hdisk1 # 3. 创建逻辑卷 applv，类型 jfs2，挂载点 /data crfs -v jfs2 -g datavg -m /data -A yes -a size=80M # 4. 验证 lsvg datavg lsvg -l datavg df -g /data

这里解释一下-a size=80M的坑：在 AIX 里给 JFS2 文件系统指定大小时，80M 指的是 80MB，但文件系统最终能用的空间会略小于这个值，系统日志和元数据会占用一小部分。如果你在 crfs 时用"卷组剩多少就指定多少"，系统可能提示空间不足。稳妥做法是留出 5% 到 10% 的余量。

如果只想建裸逻辑卷，不挂文件系统，用mklv：

# 创建 100MB 的逻辑卷 app_lv，类型 jfs2 mklv -y app_lv -t jfs2 datavg 100M

100M也可以写成 LP 个数，比如要 50 个 LP（PP 为 8MB 时相当于 400MB），直接写mklv -y app_lv -t jfs2 datavg 50。AIX 的很多命令同时支持按大小和按分区个数指定，掌握两套写法，看别人脚本时就不容易懵。

4.4 扩容场景的两套操作对照

扩容是日常最高频的变更。Linux 上如果卷组空间不够，先加 PV：

vgextend data_vg /dev/sdc lvextend -L +50G /dev/data_vg/app_lv xfs_growfs /data # xfs 文件系统；ext4 用 resize2fs

AIX 上的迁移思路一样，命令换成：

extendvg datavg hdisk2 chfs -a size=+50G /data

extendvg相当于 Linux 的vgextend，chfs同时扩展文件和文件系统，不需要先单独扩 LV。AIX 里如果想精确调整某个逻辑卷本身的大小，也有chlv一类命令，但日常文件系统扩容用chfs更安全，它会自动帮你处理好挂载点。

这里有两条经验：第一，扩容前最好先快照或备份，至少要对关键卷组执行一次备份或记录lsvg -l、lspv输出，出现问题可以快速对照。第二，在 AIX 里扩文件系统时，注意-a size=+50G的加号不能漏。漏掉加号，chfs -a size=50G /data会把文件系统严格设定为 50GB，如果当前已经 80GB，结果很可能是灾难性的。

4.5 在线迁移和条带化的进阶用法

卷管理和裸分区相比最大的优势就是"数据可以搬家"。Linux 下pvmove可以把一个 PV 上所有 PE 搬到另一个 PV，替换磁盘、调整磁盘布局时非常好用：

# 把 /dev/sdb 上的数据全部搬到 /dev/sdc pvmove /dev/sdb /dev/sdc

AIX 有对应的migratepv，可以把指定逻辑卷的数据从一个 PV 挪到另一个 PV：

# 把 datavg 卷组里 hdisk1 上属于 applv 的空间迁到 hdisk2 migratepv -l applv hdisk1 hdisk2

还有一个容易忽略的点：在 AIX 里创建逻辑卷时可以指定条带化，把连续数据分散到多个 PV 上，提升并行读写能力。方式是在mklv时加-S参数，比如：

# 在 hdisk1 和 hdisk2 上创建 200MB 逻辑卷 app_stripe，按 64KB 条带 mklv -y app_stripe -t jfs2 -S 64K datavg 200M hdisk1 hdisk2

条带化不是银弹。它解决的问题是单盘 I/O 瓶颈，但也会让单个逻辑卷的可靠性依赖所有参与条带的盘。只要其中一块盘故障，整个卷的数据都可能受影响，除非配上镜像或 RAID。我的习惯是：临时性、性能敏感且允许重做的卷，可以条带化；核心数据库卷，要么靠存储阵列自身的 RAID 保证数据安全，要么在 AIX 层用副本 + 条带组合，而不是只做一层条带。

5. 维护期踩过的坑和现在沿用至今的检查清单

5.1 PV 掉线后不能慌：恢复思路要分层

存储最怕的是物理卷掉线。Linux 环境下，你可能会看到pvs里出现 "unknown device" 字样，vgs显示卷组状态异常。很多人的第一反应是直接vgreduce --removemissing，把失去的 PV 从卷组里摘掉。但如果旧盘还在、只是因为临时链路问题掉线，直接移除会让数据丢失风险变大。

正确思路是分三步走。第一步，用pvscan、pvs确认几块 PV 在线、几块离线，能读到的先读出来。第二步，加一块替代 PV 进卷组，用pvmove把仍然可读的 PE 迁到健康 PV 上；如果旧盘已经完全损坏，再考虑迁移其他正常 PV 到新盘。第三步，确认数据迁移结束后，再执行vgreduce --removemissing data_vg，最后检查文件系统状态并补做备份。

AIX 场景也类似：磁盘故障时卷组里会出现STALE标记的 PP。系统会尽量从镜像副本恢复，这时通常用syncvg -v datavg把陈旧数据重新同步一遍来消除冲突；如果某块盘彻底坏了，会用replacepv把旧盘替换成新盘，再同步镜像。两条路径看似命令不同，核心原则一致：能先恢复数据，就不要急着物理性移除；移除之前，必须确认没有可用副本可以同步。

5.2 命名、PP 大小和镜像三个高频翻车点

先说命名。卷组、逻辑卷的名字一旦上线，改起来很痛苦。在 AIX 里，卷组名会出现在/dev下，比如datavg对应/dev/datavg。命名用_vg、_lv这种带后缀的规则，比拼音缩写或者随意编号要有可读性得多。我见过一台机器上出现zz_vg、test1、new1混着来的情况，三年后没人能说清哪个卷是干什么的。

再说 PP 大小。很多新手在mkvg时为图省事把 PP 设成 256MB 甚至 1GB。对大文件、大分区需求来说这点够用，但一旦要建几十个小逻辑卷或者做精细扩容，LP 个数会非常尴尬。反过来，PP 太小比如 1MB，在 10TB 级磁盘上会产生大量 PP 条目，元数据操作和扫描速度都会受影响。合理做法是：根据卷组未来最大卷容量倒推，让单卷的 LP 数落在几千到几万之间，通常不会错。

最后是镜像。AIX 里建议对核心数据卷创建时直接指定副本数，而不是事后补。倒不是因为事后不行，而是镜像同步过程会占用资源，在线转换时如果业务压力很大，可能影响性能。Linux 的 raid1 转换也有类似问题。我在生产变更时习惯把镜像同步安排在业务低峰期，并提前练习"模拟一块盘故障后靠副本恢复"的预案。

5.3 我每次变更前必查的清单

下面这份清单来自我这些年的维护习惯，不涉及某个厂商的封闭界面，Linux 和 AIX 都适用：

1. 记录变更前状态：Linux 保存pvs、vgs、lvs输出；AIX 保存lsvg -l、lsvg -p、lspv输出，留到一个临时文件里。
2. 确认卷组里有足够的可用空间：别只看卷组总空间，要看Free PPs或者 VG Free 这一列，不要被镜像副本数迷惑。
3. 确认目标 LV 的挂载点：AIX 里lsvg -l会显示每个 LV 对应的 MOUNT 点，Linux 用df -h和findmnt双重确认，避免扩错逻辑卷。
4. 变更前备份或快照：数据库卷如果允许，备份最新归档；文件服务至少做一次快照；不确定时宁可不扩，先和业务确认。
5. 变更后验证：df -h确认新容量生效，pvs/vgs/lvs或lsvg -l确认没有异常状态，同时观察系统日志里是否有 I/O 报错。
6. 留回滚预案：能扩的卷通常也能缩，但缩卷风险明显更大。我的经验是"能扩就不缩，缩卷必须先在测试环境完整演练一遍"。

这份清单就像汽车的后视镜，不是为了让你开得更快，而是在变道的时候少撞一次。

5.4 PV、LP 这些缩写一出场就有歧义，先对齐语境再动手

最后聊一个很容易被忽略的现实问题：VG、PV、PP、LV、LP 这些缩写，并不是存储领域的专利。在互联网运营语境里，PV 是 Page View，也就是页面浏览量，做数据分析的朋友天天都在谈日 PV、月 PV；在算法和数学优化里，LP 是 Linear Programming，线性规划；搜 "LP 波形" 的时候还可能碰到示波器里的 LP 信号概念。

所以当你在一台服务器上看到lspv、lsvg时，先确认自己是在存储卷管理语境里，再拿这套逻辑去套。尤其和业务方沟通时，对方说"我看今天 PV 涨了很多"，你千万先问清楚是页面访问量还是物理卷在线状态，不然会闹出跨语境的乌龙。技术拼的是基本功，但沟通拼的是对齐上下文——这一点在缩写满天飞的基础设施领域尤其要命。