简介：《HP 3PAR操作手册》是一份面向存储管理员与运维人员的实用指南，围绕HP 3PAR存储的初始化部署与配置展开，重点介绍管理控制台的登录使用、主机创建、CPG存储池搭建、VV虚拟卷创建及分配等核心操作，适用于数据中心、云计算、虚拟化等环境下的日常管理。资源包内含1个docx文档，整体大小3.27MB，以图文步骤说明为主，结构清晰，便于按章查阅。目前已有2377人学习下载，适合希望快速掌握HP 3PAR存储配置的技术人群。内容从管理界面身份验证讲起，覆盖创建主机时HBA卡WWN的选择与绑定、CPG的RAID类型和级别设定、VV容量与所属CPG的配置，以及将VV映射到主机时的LUN分配与对应关系核查，各环节均附有创建完成后的校验方法，可帮助读者系统梳理从存储池规划到主机上线的完整链路，减少配置疏漏与排错成本。
1. 先看懂这台3PAR的首页菜单：五步操作骨架与一个反直觉结论
接手一台HP 3PAR存储，最怕的不是容量不够，而是没人告诉你「划盘」这件事的完整链路。这份HP 3PAR存储操作手册把整个交付流程拆成五步：登录管理控制台、创建主机（HOST）、创建存储池（CPG）、创建虚拟卷（VV）、把VV分配给主机。每一步看起来像普通点选，实际操作里每一步都藏着能让业务主机永远看不到盘的坑。适合第一次接触3PAR的存储运维、虚拟化工程师，也适合已经管理过多台存储但每次配置都要翻旧文档的人。反直觉的结论是：这套配置真正难的不是点击，而是HOST、CPG、VV三个概念之间的依赖顺序——顺序对了，半小时能完成一批LUN的交付，顺序错了，光排障就能耗掉一整个下午。
2. 登录与三个核心概念：HOST、CPG、VV先理清哪一层决定能不能看到盘
3PAR的界面逻辑和传统存储不一样，它把主机、存储池、卷拆成三个独立对象，让管理员像拼积木一样组合交付。很多人一上来就点Provisioning，结果做到分配那一步才发现主机没建或者WWN不在列表里，又回头重做。要把这个流程走得顺，先搞明白登录入口和三个对象的关系。
2.1 登录管理控制台：默认凭据、界面分区与两个版本的差异
文档里给的登录入口是HP 3PAR Management Console 4.3，地址是存储控制器的管理IP，用户名3paradm，密码3pardata。这个账号是出厂管理账号，具备全局配置权限。需要提醒的是，生产环境拿到机器后第一件事是改掉这个默认密码，很多历史遗留事故都是默认凭据被扫到后，存储配置被外部直接改掉。
登录后界面主要分几个区：左侧菜单树承载配置入口，包含Hosts、Provisioning、CPGs、Virtual Volumes、Export Volumes等，中间是详情区和操作按钮，右下角是任务状态条。这份手册的操作路径全部集中在这几个菜单里。
有一个现代界面的补充：3PAR近几年把Management Console逐步替换为SSMC，界面更接近当前主流存储的Web UI风格。SSMC默认端口8443，登录逻辑与MC一致。如果你拿到的是SSMC 3.x或4.x版本，菜单名差异不大，只是「create」入口从右键变成左上角按钮，操作步骤实质相同。文档基于MC 4.3写，但原理迁移到SSMC没有障碍。
2.2 HOST、CPG、VV之间的关系：谁是谁的上一层
三个概念的依赖关系可以这样理解：HOST是消费方，代表一台业务服务器，里面装着这台服务器所有HBA卡的WWN；CPG是存储池，定义了物理磁盘以什么RAID级别和备盘策略组织起来；VV是最终给主机使用的虚拟卷，它从CPG里拿空间，再通过Export Volumes挂到HOST下面。
整个链路的顺序是固定的：先有CPG作为空间来源，再建VV从CPG分配容量，然后建HOST把主机的WWN收进来，最后把VV导出给HOST。手册把创建HOST放在第一步，但逻辑上CPG应该在划分容量之前就位。实际项目中更常见的做法是先建CPG和VV，再把新接入的主机加进来挂载，两种顺序都能完成交付，只是手册的排序更适合初次上手时按界面菜单逐个走通。
从排障角度讲，主机看不到盘，只可能是三层中的一层出了问题：WWN没进HOST、VV没建或者建错CPG、Export没做或者LUN冲突。把这三个对象的关系装进脑子里，排障范围就锁定在这三个菜单内，不用满界面乱翻。
提示：CPG、VV、HOST都是逻辑对象，删除操作不会立刻释放物理空间，3PAR有自己的空间回收机制。别在配置阶段反复删除重建，容易把空间占用情况搞乱。
2.3 界面勾选项为什么要跳过：默认值背后的行为差异
创建主机、创建CPG、创建VV第一步都有一个「不用勾选直接Next」的界面，很多新手怀疑自己漏了什么。这个界面实际上是「高级选项」入口，包含NPIV、域设置、远端复制等特性开关。日常交付场景下这些开关保持默认即可，但要知道它们各自是干什么的，避免某天需要开NPIV时找不到入口。
NPIV是光纤通道的N端口虚拟化，用于在同一个物理端口上虚拟出多个N端口ID，主要用在虚拟化环境中给不同虚拟机分配独立WWN。域设置用于多租户隔离，一个域内的管理员只能管理域内的对象。远端复制用于异步容灾，需要在两个存储之间建立RC关系。这些功能在基础交付阶段都用不到，直接跳过是正确选择。
真正需要关注的是创建界面里的核心字段：HOST名称与操作系统类型、CPG名称与RAID级别、VV名称与容量大小。这些字段的选择直接影响主机识别、性能和空间利用率，是后面章节的重点。
3. 创建主机：WWN、OS类型与多路径的边界条件
在3PAR里，主机的概念不是IP，不是主机名，而是一组WWN的集合。这个设计来源于SAN存储的本质：存储只看得到HBA卡的WWN，看不到服务器是什么操作系统、什么品牌。创建主机的过程，本质上就是告诉存储「哪些WWN属于同一台物理服务器」，以及「这台服务器是什么操作系统」。
3.1 创建Host的完整步骤：菜单路径与字段含义
实际操作路径是：左侧菜单Hosts → Common Actions → Create Host。进入创建界面后，第一屏是高级选项，保持默认不勾选，Next。第二屏填写两个核心字段：Host Name和Operating System。
Host Name是这台主机在存储上的标识，建议使用服务器的主机名或业务用途命名，例如web01或db-backup。这个名字会出现在所有后续关联视图里，命名要能一眼看出归属。Operating System下拉框里列了Windows、Linux、HP-UX、AIX、VMware等选项，这个字段不能随便选——3PAR会根据它选择默认的卷属性、多路径策略和磁盘设备队列深度。比如选错成Windows，Linux主机挂载后可能出现设备名识别异常。
第三步是选择WWN。界面左侧列出存储当前发现的所有WWN，右侧是当前主机的WWN列表。从左侧选中这台服务器HBA卡的WWN，通过箭头移动到右侧。如果WWN没有出现在左侧，界面下方有手动输入框，把WWN手工键入并添加到右侧。完成点击Finish，左侧菜单Hosts列表里就能看到新建的主机。
整个流程里最常见的错误是把两台不同服务器的WWN混进同一个Host，导致A服务器的盘被B服务器看到。集群环境或双机环境里，两台机器的WWN都加入同一个Host是正确姿势，但前提是这些机器确实需要访问同一批LUN。
3.2 WWN的格式与获取方式：三种来源和手工输入的坑
WWN全称World Wide Name，是光纤HBA卡出厂烧录的唯一标识，64位十六进制，常见格式是2f:aa:bb:cc:dd:ee:ff:11，冒号分隔，每段两位。服务器只要插着光纤卡，这张卡在网上邻居或者操作系统里都能看到WWN。
实际获取方式有三种。第一种：重启服务器进HBA卡的BIOS，通常是开机按Ctrl+Q或Ctrl+Alt+F2，HBA卡自己的配置界面里会显示WWPN和WWNN。第二种：操作系统内查询，Linux执行cat /sys/class/fc_host/host*/port_name，Windows在设备管理器里查看光纤通道HBA属性。第三种：在光纤交换机上查看，登录交换机执行switchshow，可以看到每个端口连接的设备WWN。三种方式取到的值是一致的，推荐以HBA卡BIOS显示值为准，因为那是最底层的出厂信息。
手工输入WWN有两个高频坑。一个是大小写，WWN是十六进制，字母部分大小写都能被存储识别，但建议统一大写，避免后续在脚本里做字符串匹配时失败；另一个是分隔符，3PAR的手工输入框接受冒号分隔格式，粘贴时如果从Linux终端复制可能变成无分隔符的连续字符串，也接受，但两种格式混用会让后续核对变得困难。我一般会养成习惯：所有WWN统一用大写加冒号分隔的格式，记录到资产表里，避免后期靠肉眼对比。
3.3 多路径场景：一个主机到底要加几个WWN
物理服务器为了冗余通常配两块HBA卡，分别接到两台光纤交换机，再连到存储的两个控制器端口。这种情况下，一张卡对应一个WWN，两块卡就是两个WWN，两个都要加进同一台Host。3PAR会在内部为每个WWN建立独立的路径，操作系统侧再配合多路径软件（Linux的multipath、Windows的MPIO）做路径聚合。
只加一个WWN的后果是：主机的多路径软件能看到两条路径，但实际上只有一条路径能真正访问存储，另一条路径在存储侧没有对应的WWN映射。业务流量单链路转发，链路抖动或交换机维护时直接中断，这在生产环境里属于交付事故。
虚拟化环境还需要特别注意：VMware ESXi主机通常每个主机有多个HBA，如果做的是vMotion迁移，所有ESXi主机的WWN最好都加入同一个Host对象，这样VMware能看到一致的存储视图，在主机间迁移虚拟机时路径和行为才一致。3PAR在虚拟化场景下的官方推荐做法也是把整个集群的ESXi主机WWN归入一个Host。
提示：WWN一旦录入Host，删除再重新添加不会产生额外开销，但如果Host已经挂载了VV，删除Host动作会把所有VV卸载，务必先确认业务状态。
4. 创建CPG与VV：RAID级别、容量单位与类型选择的组合算式
CPG和VV是3PAR空间管理的核心，也是最容易被参数坑到的地方。CPG决定底层数据怎么放，VV决定上层主机看到什么。两个层级各有几个关键参数，配错一个，性能或容量使用率都会出问题。这一章把两个创建操作放在一起讲，因为VV的参数直接依赖CPG的形态。
4.1 创建CPG：名称、RAID级别与备盘策略的取舍
创建路径：左侧菜单Provisioning → Create CPG。第一屏继续不勾选，直接Next。第二屏填写CPG Name，选择RAID级别和类型。
CPG名称建议包含RAID级别和用途，例如CPG_RAID6_VM或CPG_RAID1_DB_LOG，这样后续创建VV时，光看CPG名字就知道空间落在什么保护级别上，排障时不用进入CPG详情里翻配置。
RAID级别的选择是本环节最关键的决策。3PAR支持RAID 0、1、5、6，以及混合RAID。不同RAID级别的性能与空间效率差异如下表：
| RAID级别 | 最少盘数 | 空间效率 | 容错能力 | 适合场景 |
|---|---|---|---|---|
| RAID 0 | 2 | 最高（100%） | 无 | 缓存、临时空间 |
| RAID 1 | 2 | 50% | 单盘故障 | 数据库日志、系统盘 |
| RAID 5 | 3 | 67%~94% | 单盘故障 | 常规业务卷 |
| RAID 6 | 4 | 50%~88% | 双盘故障 | 大容量数据、备份 |
实际项目里用得最多的是RAID 1和RAID 6。数据库和关键业务卷放RAID 1，追求写入性能和故障切换速度；容量型业务和数据仓库放RAID 6，接受两块盘同时故障不丢数据。RAID 5在3PAR上也能跑，但大容量HDD重建时间长，近几年新交付的存储已经很少推荐。
CPG类型在界面上通常指Domain和High Availability两个维度，日常用默认值即可。还有一个选项是「Hashed」和「Linear」两种放置策略，Hashed把数据打散到整个CPG的所有磁盘上，Linear优先填满一个chunklet组再换下一组。默认Hashed适合大多数场景，Linear适合对顺序读性能有极端要求的场景，不建议新手改动。
4.2 创建VV：容量单位、类型选择与所在CPG的对应关系
创建路径：左侧菜单Provisioning → Create Virtual Volume。填写三个核心字段：VV Name、VV Size、VV Type，最后选择VV所在CPG。
VV名称与业务强关联，建议格式是「业务_用途_容量」，比如db_backup_2t或web_data_500g。注意3PAR的VV名称在存储全局唯一，不能重复。
VV Size的单位是GB或TB，界面默认可能是GB。这个地方是容量踩坑重灾区：填数字的时候心里想的是TB，界面单位是GB，填完一个500就成了500GB而不是预期的500TB。另一个单位相关的坑是磁盘厂商的TB与操作系统TB换算，按二进制算，1TB实际约等于实际可用空间的93%，预留容量时要留出文件系统开销。
VV Type有Thinly Provisioned和Fully Provisioned两个选项，对应常说的Thin和Thick。差异如下表：
| 类型 | 分配方式 | 空间占用 | 性能表现 | 适用场景 |
|---|---|---|---|---|
| Thin（精简） | 按写入量动态分配 | 初期占用极小 | 首次写入有一定开销 | 虚拟化、桌面 |
| Thick（全分配） | 创建时一次性分配 | 立即占满指定容量 | 无动态分配开销 | 数据库、核心业务 |
选择逻辑是：核心生产数据库选Thick，提前把空间占住，避免运行时动态分配引入IO抖动；虚拟化平台选Thin，多个虚拟机共享一个CPG，空间利用率大幅提升。混合使用时要盯紧CPG的剩余空间，Thin卷写满了才发现CPG无空间可扩，业务会直接hang住。
所在CPG的字段下拉框列出所有已建CPG，选择一个即可。这里有一个常见误解：VV迁移或调整容量不一定要重建，3PAR支持在线调整VV大小和迁移VV到其他CPG，但迁移过程会产生IO压力，需要评估业务低峰期。
4.3 两个容量规划的实际场景：把算式落到真实交付里
假设给一套VDI虚拟桌面环境交付存储，200个虚拟桌面，每个系统盘40GB，用户数据盘60GB，总量是200×(40+60)=20TB。200个桌面并发启动会有IO尖峰，RAID级别选RAID 6。考虑Thin模式的实际占用率，桌面系统盘和数据盘普遍只有30%到50%使用率，CPG按12TB~14TB规划就够。这里的关键是：CPG空间不等于所有VV名义容量之和，Thin模式下超配是特性，但要设好监控阈值。
另一个场景：一套Oracle数据库，数据文件1.5TB，归档日志每半小时40GB，保留3天。数据库卷必须Thick分配，1.5TB一次占满；日志卷可以Thin，但要注意归档增长速率，预留至少两天余量。CPG设置为RAID 1，数据库卷和日志卷放同一个CPG还是分开两个CPG，取决于对IO隔离的要求——分开更安全，同CPG更省空间。生产环境我一般会分开，数据库卷一个CPG，日志卷一个CPG，避免日志写入量大时和数据库抢IO。
5. 分配VV到主机：Export流程与五条避坑排错记录
CPG和VV建好后，空间只是存在那里，主机还看不见。3PAR里的最后一步是Export Volumes，把VV挂到主机上，主机配合多路径软件才能识别到盘。这一步操作本身只有几秒钟，但前面所有参数的问题都会在这一步暴露出来。这一章先把流程走通，再把这几年在3PAR上遇到的高频问题整理成排错记录。
5.1 Export Volumes的完整操作路径：界面细节与选择逻辑
操作路径：左下菜单Export Volumes → 进入分配界面。第一屏不勾选，Next。第二屏是整个分配过程的核心区域：左侧窗口列出所有可分配的VV，右侧窗口列出所有已创建的主机，从左侧选中需要分配的VV，右侧选中目标主机，WWLoLUN选择器选Auto，下一步确认分配。
LUN的Auto策略表示由3PAR自动分配主机上的LUN编号。如果一台主机需要挂多个VV，全部选Auto不会产生LUN冲突，因为3PAR会为每个主机维护独立的LUN编号空间。手工指定LUN的场景只在特殊业务需要固定盘符时使用，比如Windows环境要求某个业务盘固定为E盘。
分配动作支持一对多和多对一：一个VV可以分配给多台主机（集群共享），一台主机可以挂载多个VV（数据库多盘）。选择时要注意集群场景：给RAC集群或Hyper-V集群分配共享VV时，主机的操作系统类型必须相同，且所有节点主机的WWN都在同一Host里，否则集群识别会出问题。
5.2 常见问题与避坑：五条实践排错记录
问题一：主机WWN没有出现在左侧选择框里现象：创建主机时，左侧WWN列表里找不到新接入服务器的WWN，右侧主机已经存在但没法把WWN关联进去。 原因：光纤链路未打通。存储的端口没有识别到HBA卡的登录，Zoning未配置或者光纤线松动。 解决：先在光纤交换机上查switchshow确认WWN是否在线；确认Zoning里该WWN与存储端口在同一Zone；再回到3PAR界面点击刷新或重新扫描Port。操作顺序是先交换机层面排通，再查存储的端口事件日志。
问题二：VV分配给主机后，Linux主机fdisk -l看不到盘现象：Export Volumes界面显示VV已分配，LUN状态正常，但操作系统的fdisk或lsscsi输出里没有任何新磁盘。 原因：操作系统类型选错。创建Host时OS类型选了Windows或VMware，但实际系统是Linux，导致3PAR下发的设备参数对不上。 解决：编辑Host的操作系统类型改为Linux，重新扫描SCSI总线。修改动作不影响已分配的VV，但部分操作系统需要重启或重新扫描才能识别新设备属性。
问题三：多路径状态只有一条路径正常现象：主机端multipath -ll显示一个盘对应两条路径，但一条active一条failed。 原因：主机的两个HBA卡WWN只加了一个到Host，存储侧只有一条路径有VV映射。 解决：把另一个WWN补充到Host里。补充后存储侧会自动为所有VV创建新路径，主机端重新扫描后多路径软件会收拢路径。
问题四：两台主机分配了同一个VV，导致文件系统损坏现象：业务报文件系统异常，检查发现同一个VV被Export给了多个不相关的主机，两台主机同时挂载同一个文件系统，数据写入互相覆盖。 原因：分配时从左侧顺手把VV选到了多个Host，或者从VV视图看到已分配列表里存在多个Host关联。 解决：非集群场景下，立即卸载其中一台主机的VV映射，检查文件系统完整性。集群场景必须先确认集群软件已处理锁机制，否则同样危险。
问题五：VG和LUN容量对不上，DD显示比分配值小现象：分配1TB的VV，操作系统里fdisk看到999GB或更小，数据库认为空间不足。 原因：容量单位换算，以及文件系统元数据开销。3PAR的VV按二进制GB换算，操作系统的设备容量显示也按二进制，但磁盘厂商习惯十进制，中间差约7%，再加文件系统自身元数据占用。 解决：分配时按目标可用量加7%到10%预留。比如数据库要求1TB可用，VV建1.1TB到1.2TB，操作系统里格式化后可用量才真正够。
提示：排障时不要只盯着3PAR界面看，先确认存储侧VV导出状态，再确认光纤交换机Zoning，最后是主机操作系统识别。顺序反过来查，容易在界面上浪费时间。
6. 验证与收尾：用CLI命令而不是界面截图确认交付成功
界面显示分配完成，不等于业务侧真的能用。我见过太多次界面显示VV已导出到Host，结果光纤链路或者多路径配置有问题，业务主机始终看不到盘。后来养成一个习惯：所有3PAR配置完成后，都通过命令行做一次全链路确认，再交给业务方挂载。
3PAR控制器上内置CLI，通过SSH登录到存储的管理IP，端口22，账号为3paradm。登录后执行命令验证配置状态。以下是一组最常用的验证命令，按顺序跑一遍，等于把整条链路从CPG到主机重新检查一遍：
# 查看CPG整体空间与RAID状态 showcpg -r # 查看所有VV，包括容量、类型与所在CPG showvv -a # 查看Host列表以及每个Host的WWN showhost # 查看VV到主机的映射关系，输出LUN号与状态 showvlun -a # 查看Host的详细状态，确认操作系统类型与WWN数量 showhost <host_name>这些命令配合输出的字段可以快速定位问题。showcpg -r输出里的Usable容量与Free容量用来确认空间余量；showvv -a里Type字段显示VV是thin还是thick；showhost输出里Num Ports字段显示WWN数量，如果一台物理双HBA服务器显示只有1个端口，说明WWN没加全；showvlun -a的Lun和Active字段确认映射是否在活动状态。
CLI输出的另一个价值是把配置状态导成文本留档。存储交付后把showvv、showhost、showvlun的结果保存到运维资产目录，变更时对比前后差异，比翻界面截图可靠得多。界面截图只能证明你看过界面，命令输出能证明存储的真实状态。
配置完成后还有一套三分钟巡检习惯：先用showcpg确认CPG剩余空间不低于计划阈值，再用showvv确认新VV状态为normal，然后用showvlun确认映射关系已建立，最后到主机端执行rescan-scsi-bus.sh或者Windows的重新扫描磁盘，确认设备清单里出现预期容量的新盘。这四步走完，才算一次真正闭环的交付。
存储配置这类工作，界面点击永远是最后一公里之前的动作，真正的验证发生在命令行和业务侧。从那以后我每次做完3PAR变更都强制走一遍CLI验证加主机端确认的双重流程，这套习惯让我从当初对着界面发懵的新手变成了能把配置一次交付到位的执行者。希望帮到你。
本文还有配套的精品资源，点击获取
