简介：HP 3PAR操作手册面向存储运维人员与刚接触高端存储的初学者，围绕3PAR存储从初始化到卷分配的核心配置流程展开，帮助读者在没有实机经验的情况下建立完整操作框架。压缩包内仅含1个docx文档，体积约3.27MB，以图文步骤形式编排，篇幅精炼、便于随身查阅与打印。内容覆盖HP 3PAR Management Console登录验证、创建主机并绑定HBA卡WWN、创建CPG并选择RAID级别与类型、创建虚拟卷VV、将VV导出分配给主机并设置LUN等关键环节，同时简述HOST、CPG、VV等基本概念与常见应用场景，步骤中附带菜单路径截图，可对照复现。目前已有2391人学习下载，适合作为日常巡检、割接实施前的速查手册与新人培训材料。

1. 一句话说清 HP 3PAR 存储：它其实是个「会自己切柜子的仓库」

很多人第一次站到机房里那一整柜亮着绿灯的硬盘前面，都会冒出一个很朴素的疑问：这些盘到底是怎么变成服务器上一个能格式化、能装系统的设备的？HP 3PAR 存储要回答的就是这个问题。你可以把它想象成一座自动化仓库：库管员手上有成排的货架，随时能按订单把货架切成小格子租给不同的租客。租客只看得到自己那个格子和门口那张单据，看不到也不关心货架背后是几块盘、怎么排布、坏一块会怎样。整套管理动作，说到底就是围绕四件事转——谁要货、从哪块货架切、切多少、怎么送到门口。把这四件事对应到界面上，就是建主机、建存储池、建虚拟卷、把卷分配给主机。搞懂这四个动作分别在答什么问题，手册里那些看起来重复的「下一步」就不再是玄学。

2. 为什么要分三层：HOST、CPG、VV 各答一个问题

刚翻操作手册的人最容易冒出的念头是：不就是给服务器分块盘吗，为什么要点五次向导？答案藏在分层里。存储这行有个反复被验证的经验：凡是把「谁用、从哪来、给多少」搅在一起的设计，用不到半年就会变成一团乱麻。三层结构不是为了显得专业，而是把三个会独立变化的东西拆开，让它们各自变化时不去牵连另外两个。

2.1 HOST：先回答「谁」才有资格用

在光纤通道的存储网络里，服务器不是靠名字被认出来的。阵列不认识你那台机器叫什么，它只认 HBA 卡上的 WWN——一串十六位的十六进制数字，出厂就烧在卡里，全球唯一。所以「建 HOST」这个动作的本质，是在阵列里登记一条白名单：这串号码属于某个业务主机。

这解释了一个新手常犯的迷糊：为什么我把卷分出去了，服务器还是看不到？很可能就是 HOST 这一关卡住了。WWN 少写一位、多写一位、把两块卡的号码填串了，阵列都会老老实实认为「这台主机不存在」，然后把卷晾在那儿。

手册里有一句很容易被一眼扫过的话：如果主机的 HBA 卡 WWN 在左侧候选框里没列出来，就要手动在下方输入框里敲进去再添加。这里的候选框，是阵列主动扫到的、还没被任何主机认领的 WWN。没扫到通常意味着三件事之一：链路没通、交换机侧的 zoning 没配对、或者线插错了端口。这时候正确的动作是回去查链路，而不是硬把那串数字敲进去——敲进去阵列会接受，但服务器照样看不到，排查难度反而更大。

建 HOST 时还要选一个操作系统类型。这个选项不影响容量，影响的是阵列对这台主机的「脾气判断」：不同系统对超时、队列深度、多路径的行为不一样，选错了不会立刻报错，但会在业务高峰期以莫名其妙的慢或者路径抖动的方式表现出来。这类问题最难查，因为日志里什么都正常。

2.2 CPG：存储池和 RAID 都藏在这一层

CPG 的全称是 Common Provisioning Group，中文一般叫存储池或者通用配置组。名字里的 Common 是「公共」的意思——它是一块被许多卷共享的资源池，不是给某一个业务专用的。

物理盘先被纳管进阵列，再被划进某个 CPG。CPG 这一层一次性定了三件事：用哪一类盘、用什么 RAID 级别、以多大的粒度增长。第一件决定性能天花板，第二件决定坏盘时能扛几块，第三件决定容量账算得细不细。

打个比方，CPG 就是仓库里划出来的一个货架区。你规定了这一区放什么规格的箱子、几层叠放、每层留多宽的位置。后面所有从这个区里切出去的格子，都自动继承这套规矩。

为什么非要这一层？因为如果每建一个卷都直接去指定物理盘，几十台服务器、几百个卷，某块盘一坏，配置就得逐个改一遍。有了池子，冗余策略在池层面定一次，后面切出来的卷全部继承；要换性能档位，新建一个池子把新卷放进去，老卷原地不动。管理动作的颗粒度从「每块盘」上移到了「每类盘」。

2.3 VV：真正交付到服务器手上的那一卷

VV 是 Virtual Volume，虚拟卷。它是从某个 CPG 里切出来的一段逻辑空间，有名字、有大小、有形态。服务器最终认到的那块「盘」，就是它。

VV 和 CPG 的关系，像从货架区里划出一个具体格子。格子的尺寸你说了算，但格子背后占多少物理资源，由货架区统一调度。这也是为什么同一块池子里能切出大小差很多、形态也不同的卷。

形态这一项值得单独说。精简置备（thin）的卷在建的时候只记账不真给盘，写多少消耗多少；完整置备（full）的卷建的时候就把空间实打实圈走，哪怕一个字没写。前者灵活但需要盯着容量水位，后者踏实但容易浪费。这个区别在第四章会展开，这里先记住一点：手册里选类型那一步，选的不是容量，是「这块空间的记账方式」。

2.4 三层拆开的代价与收益

拆层的收益是解耦：主机身份变了只改 HOST，性能策略变了只动 CPG，容量不够只加 VV，三者互不牵连。代价是多了一层概念要记，而且顺序被依赖关系锁死了——你不能先建 VV 再建 CPG，因为卷必须落在某个池子里；也不能先分配再建 HOST，因为分配这一步要指定收件人。

把这张表记住，手册里五个动作就不再是五件独立的事，而是一条链上的五个环。

3. 从建主机到卷被看见：五个动作各自在解决什么

流程本身不复杂，复杂的是每一步背后那些没说出口的默认值。手册按截图一路 next 走下来能建成功，但成功了不等于建对了。这一章把五个动作拆开，看看每一步到底在定什么、默认值为什么是那样、什么时候需要改。

3.1 登录管理控制台：先看清界面在管什么

管理控制台是图形化的管理入口，登录进去看到的左侧导航栏，基本就是这台阵列的全部管理面。常用的几项包括 Host（主机）、Provisioning 下的 CPG 与 Virtual Volume、以及 Export Volumes（把卷分出去）。

导航栏的排列顺序其实暗示了使用顺序：先有人，再有池，再有卷，最后有分配。把界面当成一个「状态机」来看，比把它当成一堆功能菜单要好理解得多——每建完一样东西，左侧对应列表里就多一条记录，这条记录会被下一步引用。

登录本身没有太多可讲的，唯一值得提醒的是账号权限。日常划卷和改配置用的不是同一个级别的账号，前者应该用权限更窄的账号。这条在手册里往往不写，但真出问题时，操作日志里能看出是谁动的手，比事后大家一起回忆有用得多。

3.2 建 HOST：WWN 不在列表里怎么办

进 Host 页面，从操作菜单里选创建，向导第一步通常有个复选框，手册明确写了「不用勾选」。这类选项一般和批量创建或者套用现有配置有关，勾上之后后面的向导分支会变，多出一堆你暂时用不到的输入框。第一次建就老老实实不勾，路径最短。

第二步填主机名、选操作系统类型。主机名是给人看的，随便起，但要起得能认人；系统类型是给阵列看的，得选对。

第三步最关键：从左框里把这个主机的 HBA 卡 WWN 挑到右框。一台服务器通常有两块卡、四个端口，多路径要靠它们。挑的时候要确认每一串号码对应的物理端口，别一股脑全拖过去——把不属于这台机器的号码加进来，轻则多出一条永远不活动的路径，重则影响另一台主机的识别。

如果候选框里空空如也，前面说过，先查链路再考虑手输。手输时的格式要严格对齐，十六位十六进制，大小写不敏感但位数一个不能少。

用命令行做的事是一样的：

# 登记主机：主机名 + 端口 WWN，persona 决定阵列对这台机器的行为预设 createhost -persona <系统类型编号> app_host_01 10000000C9A1B2C3 # 建完确认一下，看 WWN 有没有录错 showhost

第一条命令里，主机名和 WWN 是必须的，persona 那一项对应界面上的操作系统类型。第二条是查证，养成建完就查的习惯，比事后从业务侧倒推要省事得多。

3.3 建 CPG：RAID 与盘型的组合决定了后面所有 VV

进 Provisioning 菜单下的创建 CPG，同样先遇到那个不用勾的复选框。然后填名字、选 RAID 级别和盘型。

这一步是整个流程里最需要想清楚的地方，因为它一旦定下来，从这个池子里切出去的所有卷都继承这套策略，后面改不了——只能新建一个池子把新卷放进去，老卷原地不动。

RAID 级别怎么选，取决于业务是「读多写少」还是「小随机写多」。镜像是两副本，写性能好、重建快，但容量只用一半；单校验利用率高，读性能好，写有小惩罚，一块盘坏了能扛住；双校验能同时扛两块，但写惩罚更重，小随机写场景下性能下降明显；镜像加条带兼顾性能和可靠性，代价是成本。判断依据不是数字大小，是业务的 IO 特征和盘的数量。

盘型的选择同理。高速盘放热点业务，大容量近线盘放归档和备份，混着放的结果通常是两头不讨好。

# 建池子：盘型与 RAID 级别在这里一次定死 createcpg -sa raid5 pool_app # 查一下池子的可用容量和告警水位 showcpg

第二条命令的输出里有几列值得盯：总容量、已用、以及增长粒度。增长粒度决定了这个池子扩容时是以多大为单位往上加的，粒度太细管理开销大，太粗容易浪费。

3.4 建 VV：大小、类型、落在哪

从 Provisioning 菜单进创建虚拟卷，填名字、填大小、选类型、选落在哪个 CPG，然后完成。

名字和大小是显性的，容易忽略的是类型。精简置备在建的时候只登记一个「欠条」，实际占用随写入增长；完整置备当场把空间圈走。前者的好处是初期不浪费，坏处是容量水位需要人盯着；后者反过来。

另一个容易忽略的点是「落在哪个 CPG」。同一个业务的不同卷，如果 IO 特征差别大，完全可以分开放到两个池子里，而不是全塞进一个。这一步多花三十秒，后面性能出问题时少排查三天。

# 从池子里切一个精简卷出来 createvv -tpvv pool_app vv_app_data_01 500g # 确认卷建在了预期的池子里 showvv -cpg pool_app

第一条里的-tpvv就是精简置备的开关，去掉它建出来的就是完整置备。第二条按池子过滤看卷列表，比在几百个卷里翻要快。

3.5 分配：LUN 为什么建议勾自动

最后一步是把卷分给主机。进分配页面，左侧选卷，右侧选主机，LUN 那一项勾自动，完成。

LUN 是服务器侧看到的编号，相当于「这块盘插在服务器的第几个槽位」。手动指定不是不行，但如果两台机器各自手动指定、又恰好撞号，后面排查起来非常难受。勾自动让阵列在目标主机名下挑一个没被占用的编号，省掉这类低级冲突。

这一步还支持两种批量方式：多个卷分给一台主机，或者一个卷分给多台主机。前者用于给单机扩容量，后者用于集群共享场景。要注意的是共享场景下，多台主机必须都能识别同一块卷，文件系统层面还需要额外的集群锁机制，否则两边同时写会把数据写花。

# 把卷映射给主机，LUN 号由阵列指定 createvlun vv_app_data_01 1 app_host_01 # 确认映射关系 showvlun

做完这一步，界面上会显示卷与主机的对应关系。但「显示已分配」和「服务器真的能用」之间还差好几步，这一点在第四章会单独说。

4. 常见误区与易混概念：CPG、VV、LUN 到底谁的谁

这套东西的概念不多，但相互之间的边界很细，新手翻车大多不是因为不会点按钮，而是因为脑子里某两个概念糊在了一起。下面五条是最常见的。

4.1 误区一：建了 CPG 就等于占了空间

易混点：把 CPG 当成一个已经圈好的大硬盘。

为什么会混：CPG 名字里带 Group，听起来像「一组已经分好的盘」；界面上它也确实显示一个容量数字。

怎么区分：CPG 是「可分配的上限」，VV 才是「实际划出去的份额」。池子建好之后，物理空间并没有因此减少，减少发生在你从池子里切出完整置备的卷、或者精简卷被真正写入的时候。换句话说，CPG 是一张额度卡，VV 是刷卡记录。看容量要看两个数：池子还剩多少可以分，以及池子背后物理上还剩多少可用。

4.2 误区二：WWN 就是 IP，或者就是主机名

易混点：以为三者是一回事，或者以为能像 ping 地址那样验证 WWN 通不通。

为什么会混：它们都是「一串标识」，看起来都像地址，都在配置界面里出现。

怎么区分：三个不同的层。WWN 是光纤通道这一层的硬件地址，烧在卡上，换卡就换号；IP 是网络层的逻辑地址，可以随时改；主机名是人起的标签，可以重名，可以在阵列里随便写。判断方法很简单——改主机名，阵列和服务器之间的连接不受影响；改 WWN 的登记，连接立刻断。搞清楚这点，排查「卷看不到」时就知道先看哪一层。

4.3 误区三：精简置备等于可以随便超配

易混点：把 thin 当成免费扩容，觉得反正建的时候不占地方。

为什么会混：建的时候确实一点都不占，几百 G 的卷秒建完，很容易产生「空间无限」的错觉。

怎么区分：thin 只是把「付账」的时间推后了，账迟早要结。超配比例必须设上限，池子的剩余容量要设告警水位。真正危险的场景不是慢慢写满，而是某天业务集中写入，池子在几分钟内被吃干，那一刻所有精简卷一起写不进去，表现是业务层面的大面积卡死。稳妥的做法是把超配控制在可预期的范围内，并且定期看池子的增长趋势，而不是等告警响。

4.4 误区四：RAID 数字越大越安全

易混点：默认双校验比单校验好，镜像加条带比两者都好。

为什么会混：数字大、名字长，听起来就更强。

怎么区分：这几个级别是在容量利用率、读性能、写性能、重建风险之间做不同的取舍，没有全局最优。双校验能同时扛两块盘，但每次写要算两遍校验，小随机写密集的场景下性能掉得肉眼可见；单校验在盘数量多的时候，重建一块盘的耗时和二次故障风险都会上升。选型的依据是业务的 IO 特征加上池子里的盘数，不是「哪个更高级」。

4.5 误区五：分配成功就等于服务器能用

易混点：看到界面上显示已分配，就认为活儿干完了。

为什么会混：管理端的状态确实是「已完成」，关系表里也清清楚楚。

怎么区分：分配只是把路径打通了，让服务器有资格看见这块盘。服务器侧还有一串动作：重新扫描总线、确认认到新设备、分区、格式化、挂载。少任何一步都看不到。反过来，如果扫描之后仍然没有，优先怀疑两件事——交换机侧的 zoning 有没有放行，以及 HOST 里登记的 WWN 有没有错一位。这两种情况在管理端看起来都「一切正常」，只能从服务器侧反查。

5. 容量、命名与顺序：手册截图之外的三件事

截图能告诉你按钮在哪，但告诉不了你为什么这么点。有三件事，手册里通常不写，却是踩坑最集中的地方。

5.1 顺序是被依赖关系锁死的

四个动作的顺序不是习惯问题，是依赖问题：卷必须落在池子里，所以池子在前；分配必须指定收件人，所以主机在前。想跳过任何一步，界面会直接不让你继续。

真正值得说的是向导里那些「不用勾选」的复选框。手册连续几处都写了这四个字，说明写手册的人被问过很多次。这类选项一般和「批量创建」或者「套用已有配置」有关，勾上之后向导会多出一层分支，本该填一个的地方变成填一批。第一次配置时老老实实不勾，路径最短、出错面最小；等把单条流程走顺了，再回头研究批量。

还有一个隐蔽的顺序问题：给已有主机扩容时，很多人会直接去建卷、然后分配，跳过了检查主机是否还在线。如果这台主机的 HBA 卡刚换过，WWN 已经变了，新卷分配下去照样看不到。稳妥的做法是每次变更前先扫一眼主机列表和它的 WWN 登记。

5.2 容量账要分两本算

新手最容易在这里懵：池子显示还剩 500G，为什么建了一个 500G 的卷还能再建？

因为有两本账。第一本是物理账：池子背后真正可用的空间，扣掉 RAID 开销之后剩下的部分。四块 1T 的盘做单校验，可用大概三块的样子，这是物理上限。第二本是逻辑账：池子里所有卷的标称大小之和。精简卷的标称大小可以超过物理可用，超出部分靠超配额度撑着。

判断该不该继续建卷，看的是物理可用和增长趋势，不是逻辑剩余。这条经验是用一次业务卡死换来的，后面会再提。

5.3 命名是一年后救命的東西

建到第一百个卷的时候，名字的重要性会突然显现。界面上没有「备注」字段，也没有标签体系，你能依靠的只有名字本身。

一套能活过一年的命名规则，至少包含三段：环境、业务、用途，必要的话再加序号。环境区分生产、测试、灾备；业务区分是哪个系统；用途区分数据、日志、备份。三段之间用短横线连起来，全小写，不用空格和特殊字符。

# 命名模板示意，前缀顺序固定，方便按前缀过滤 # <环境>-<业务>-<用途>-<序号> # 例：prd-order-data-01 # 按前缀查一批卷 showvv | grep prd-order

第一段注释说明模板，第二段是查询示例。前缀固定下来之后，命令行里一个过滤就能把某个业务的全部卷捞出来，比在图形界面里一页页翻快得多。主机名和池子名同理，池子名里带上盘型前缀，看一眼就知道这个池子是高速还是大容量。

6. 什么时候该用这套流程，什么时候别硬套

这套五步流程最适合的场景很明确：从零给一台新服务器配上存储，或者给一台已有服务器扩一块新卷。前者走完整流程，后者从第三步开始。它的好处是每一步都有明确的检查点，建完一样能在左侧列表里看到一样，出问题时能快速定位到是哪一环断了。

但如果场景稍微偏一点，硬套就会难受。比如已经有自动化平台在统一管存储资源，手工去界面上点，平台那边的资源台账会和实际对不上，下次它自动分配时可能撞到一个你以为空着的卷。再比如只是想知道容量够不够、性能有没有跑满，那根本不需要建任何东西，看监控和池子状态就够了。还有一种情况最该克制：阵列本身正在告警、某块盘在重建、或者控制器刚切过，这时候做变更会把原本能自愈的状态搅乱，等它稳下来再动手。

有个细节值得单独拎出来：这套流程里最容易出事的不是建，是「建完之后」。卷分下去了，服务器侧却迟迟认不到，人就开始怀疑阵列、怀疑交换机、怀疑驱动，一圈查下来发现是 HOST 里那串 WWN 抄的时候少敲了一位。这种错在管理端看起来完全正常，因为它确实「分配成功」了。

我自己的习惯是，每次点完成之前，强制把那台主机的 WWN 复制出来和服务器侧的输出比对一遍，字符一个不差才继续。这条规矩是被一次半夜的扩容事故教出来的——当时卷分配完，业务扫不到盘，两边来回查了两个多小时，最后发现是登记时把两个端口的号码写反了，多路径认到了一个不存在的路径上。从那以后我每次动存储配置，都先把主机列表和池子剩余容量各看一遍，再开始点第一步。希望这些能帮你少走一段弯路。

手册本身覆盖了完整流程和每一步的界面位置，照着走能把事做完；至于每一步为什么这么定、哪些默认值不能乱改，上面这些就是补充。需要对照实操的时候，翻到对应章节一步步来即可。

本文还有配套的精品资源，点击获取