简介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因为分配这一步要指定收件人。层回答的问题关键参数建错了会怎样HOST谁有资格用主机名、系统类型、WWN卷分出去了服务器也看不到CPG从哪切、什么性能盘类型、RAID 级别、增长粒度性能不达标或容量算不准VV切多少、什么形态名称、大小、thin/full容量对不上或空间莫名吃紧把这张表记住手册里五个动作就不再是五件独立的事而是一条链上的五个环。3. 从建主机到卷被看见五个动作各自在解决什么流程本身不复杂复杂的是每一步背后那些没说出口的默认值。手册按截图一路 next 走下来能建成功但成功了不等于建对了。这一章把五个动作拆开看看每一步到底在定什么、默认值为什么是那样、什么时候需要改。3.1 登录管理控制台先看清界面在管什么管理控制台是图形化的管理入口登录进去看到的左侧导航栏基本就是这台阵列的全部管理面。常用的几项包括 Host主机、Provisioning 下的 CPG 与 Virtual Volume、以及 Export Volumes把卷分出去。导航栏的排列顺序其实暗示了使用顺序先有人再有池再有卷最后有分配。把界面当成一个「状态机」来看比把它当成一堆功能菜单要好理解得多——每建完一样东西左侧对应列表里就多一条记录这条记录会被下一步引用。登录本身没有太多可讲的唯一值得提醒的是账号权限。日常划卷和改配置用的不是同一个级别的账号前者应该用权限更窄的账号。这条在手册里往往不写但真出问题时操作日志里能看出是谁动的手比事后大家一起回忆有用得多。3.2 建 HOSTWWN 不在列表里怎么办进 Host 页面从操作菜单里选创建向导第一步通常有个复选框手册明确写了「不用勾选」。这类选项一般和批量创建或者套用现有配置有关勾上之后后面的向导分支会变多出一堆你暂时用不到的输入框。第一次建就老老实实不勾路径最短。第二步填主机名、选操作系统类型。主机名是给人看的随便起但要起得能认人系统类型是给阵列看的得选对。第三步最关键从左框里把这个主机的 HBA 卡 WWN 挑到右框。一台服务器通常有两块卡、四个端口多路径要靠它们。挑的时候要确认每一串号码对应的物理端口别一股脑全拖过去——把不属于这台机器的号码加进来轻则多出一条永远不活动的路径重则影响另一台主机的识别。如果候选框里空空如也前面说过先查链路再考虑手输。手输时的格式要严格对齐十六位十六进制大小写不敏感但位数一个不能少。用命令行做的事是一样的# 登记主机主机名 端口 WWNpersona 决定阵列对这台机器的行为预设 createhost -persona 系统类型编号 app_host_01 10000000C9A1B2C3 # 建完确认一下看 WWN 有没有录错 showhost第一条命令里主机名和 WWN 是必须的persona 那一项对应界面上的操作系统类型。第二条是查证养成建完就查的习惯比事后从业务侧倒推要省事得多。3.3 建 CPGRAID 与盘型的组合决定了后面所有 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. 什么时候该用这套流程什么时候别硬套这套五步流程最适合的场景很明确从零给一台新服务器配上存储或者给一台已有服务器扩一块新卷。前者走完整流程后者从第三步开始。它的好处是每一步都有明确的检查点建完一样能在左侧列表里看到一样出问题时能快速定位到是哪一环断了。但如果场景稍微偏一点硬套就会难受。比如已经有自动化平台在统一管存储资源手工去界面上点平台那边的资源台账会和实际对不上下次它自动分配时可能撞到一个你以为空着的卷。再比如只是想知道容量够不够、性能有没有跑满那根本不需要建任何东西看监控和池子状态就够了。还有一种情况最该克制阵列本身正在告警、某块盘在重建、或者控制器刚切过这时候做变更会把原本能自愈的状态搅乱等它稳下来再动手。场景建议做法新服务器首次配存储走完整五步一步不跳已有主机扩容从建卷开始分配前先核对 WWN已有自动化平台接管手工只做只读检查变更交给平台阵列告警或重建中只观察不操作等状态恢复只查容量与性能看池子与卷列表不动配置有个细节值得单独拎出来这套流程里最容易出事的不是建是「建完之后」。卷分下去了服务器侧却迟迟认不到人就开始怀疑阵列、怀疑交换机、怀疑驱动一圈查下来发现是 HOST 里那串 WWN 抄的时候少敲了一位。这种错在管理端看起来完全正常因为它确实「分配成功」了。我自己的习惯是每次点完成之前强制把那台主机的 WWN 复制出来和服务器侧的输出比对一遍字符一个不差才继续。这条规矩是被一次半夜的扩容事故教出来的——当时卷分配完业务扫不到盘两边来回查了两个多小时最后发现是登记时把两个端口的号码写反了多路径认到了一个不存在的路径上。从那以后我每次动存储配置都先把主机列表和池子剩余容量各看一遍再开始点第一步。希望这些能帮你少走一段弯路。手册本身覆盖了完整流程和每一步的界面位置照着走能把事做完至于每一步为什么这么定、哪些默认值不能乱改上面这些就是补充。需要对照实操的时候翻到对应章节一步步来即可。本文还有配套的精品资源点击获取 
长河君 · 2026/10/28 11:36:00 · 阅读 1.2k HP 3PAR存储配置核心：HOST、CPG、VV分层与LUN分配
简介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因为分配这一步要指定收件人。层回答的问题关键参数建错了会怎样HOST谁有资格用主机名、系统类型、WWN卷分出去了服务器也看不到CPG从哪切、什么性能盘类型、RAID 级别、增长粒度性能不达标或容量算不准VV切多少、什么形态名称、大小、thin/full容量对不上或空间莫名吃紧把这张表记住手册里五个动作就不再是五件独立的事而是一条链上的五个环。3. 从建主机到卷被看见五个动作各自在解决什么流程本身不复杂复杂的是每一步背后那些没说出口的默认值。手册按截图一路 next 走下来能建成功但成功了不等于建对了。这一章把五个动作拆开看看每一步到底在定什么、默认值为什么是那样、什么时候需要改。3.1 登录管理控制台先看清界面在管什么管理控制台是图形化的管理入口登录进去看到的左侧导航栏基本就是这台阵列的全部管理面。常用的几项包括 Host主机、Provisioning 下的 CPG 与 Virtual Volume、以及 Export Volumes把卷分出去。导航栏的排列顺序其实暗示了使用顺序先有人再有池再有卷最后有分配。把界面当成一个「状态机」来看比把它当成一堆功能菜单要好理解得多——每建完一样东西左侧对应列表里就多一条记录这条记录会被下一步引用。登录本身没有太多可讲的唯一值得提醒的是账号权限。日常划卷和改配置用的不是同一个级别的账号前者应该用权限更窄的账号。这条在手册里往往不写但真出问题时操作日志里能看出是谁动的手比事后大家一起回忆有用得多。3.2 建 HOSTWWN 不在列表里怎么办进 Host 页面从操作菜单里选创建向导第一步通常有个复选框手册明确写了「不用勾选」。这类选项一般和批量创建或者套用现有配置有关勾上之后后面的向导分支会变多出一堆你暂时用不到的输入框。第一次建就老老实实不勾路径最短。第二步填主机名、选操作系统类型。主机名是给人看的随便起但要起得能认人系统类型是给阵列看的得选对。第三步最关键从左框里把这个主机的 HBA 卡 WWN 挑到右框。一台服务器通常有两块卡、四个端口多路径要靠它们。挑的时候要确认每一串号码对应的物理端口别一股脑全拖过去——把不属于这台机器的号码加进来轻则多出一条永远不活动的路径重则影响另一台主机的识别。如果候选框里空空如也前面说过先查链路再考虑手输。手输时的格式要严格对齐十六位十六进制大小写不敏感但位数一个不能少。用命令行做的事是一样的# 登记主机主机名 端口 WWNpersona 决定阵列对这台机器的行为预设 createhost -persona 系统类型编号 app_host_01 10000000C9A1B2C3 # 建完确认一下看 WWN 有没有录错 showhost第一条命令里主机名和 WWN 是必须的persona 那一项对应界面上的操作系统类型。第二条是查证养成建完就查的习惯比事后从业务侧倒推要省事得多。3.3 建 CPGRAID 与盘型的组合决定了后面所有 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. 什么时候该用这套流程什么时候别硬套这套五步流程最适合的场景很明确从零给一台新服务器配上存储或者给一台已有服务器扩一块新卷。前者走完整流程后者从第三步开始。它的好处是每一步都有明确的检查点建完一样能在左侧列表里看到一样出问题时能快速定位到是哪一环断了。但如果场景稍微偏一点硬套就会难受。比如已经有自动化平台在统一管存储资源手工去界面上点平台那边的资源台账会和实际对不上下次它自动分配时可能撞到一个你以为空着的卷。再比如只是想知道容量够不够、性能有没有跑满那根本不需要建任何东西看监控和池子状态就够了。还有一种情况最该克制阵列本身正在告警、某块盘在重建、或者控制器刚切过这时候做变更会把原本能自愈的状态搅乱等它稳下来再动手。场景建议做法新服务器首次配存储走完整五步一步不跳已有主机扩容从建卷开始分配前先核对 WWN已有自动化平台接管手工只做只读检查变更交给平台阵列告警或重建中只观察不操作等状态恢复只查容量与性能看池子与卷列表不动配置有个细节值得单独拎出来这套流程里最容易出事的不是建是「建完之后」。卷分下去了服务器侧却迟迟认不到人就开始怀疑阵列、怀疑交换机、怀疑驱动一圈查下来发现是 HOST 里那串 WWN 抄的时候少敲了一位。这种错在管理端看起来完全正常因为它确实「分配成功」了。我自己的习惯是每次点完成之前强制把那台主机的 WWN 复制出来和服务器侧的输出比对一遍字符一个不差才继续。这条规矩是被一次半夜的扩容事故教出来的——当时卷分配完业务扫不到盘两边来回查了两个多小时最后发现是登记时把两个端口的号码写反了多路径认到了一个不存在的路径上。从那以后我每次动存储配置都先把主机列表和池子剩余容量各看一遍再开始点第一步。希望这些能帮你少走一段弯路。手册本身覆盖了完整流程和每一步的界面位置照着走能把事做完至于每一步为什么这么定、哪些默认值不能乱改上面这些就是补充。需要对照实操的时候翻到对应章节一步步来即可。本文还有配套的精品资源点击获取